14:04:22 <senator> #startmeeting Developer Meeting 2013-08-27 14:04:22 <pinesol_green> Meeting started Tue Aug 27 14:04:22 2013 US/Eastern. The chair is senator. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:04:22 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:04:22 <pinesol_green> The meeting name has been set to 'developer_meeting_2013_08_27' 14:04:26 <senator> boom 14:04:33 <remingtron> senator++ 14:04:35 <jeff> senator++ 14:04:38 <jeff> :-) 14:04:40 <senator> #topic Introductions 14:04:42 <kmlussier> senator:++ 14:04:58 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC 14:04:58 <senator> #info senator = Lebbeous Fogle-Weekley, Equinox Software 14:05:06 * phasefx = Jason Etheridge, senator-cohort 14:05:10 <jeffdavis> #info jeffdavis = Jeff Davis, Sitka 14:05:11 <eeevil> #info eeevil = Mike Rylander, ESI 14:05:12 <RoganH> #info RoganH = Rogan Hamby, SCLENDS 14:05:22 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College) 14:05:23 <csharp> #info csharp = Chris Sharp, GPLS 14:05:24 <kmlussier> #info agenda is at http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2013-08-27 14:05:24 <remingtron> #info remingtron Remington Steed, Hekman Library (Calvin College) 14:05:29 <phasefx> #info phasefx = Jason Etheridge, ESI 14:05:35 <Dyrcona> #info Dyrcona = Jason Stephenson, MVLC 14:05:39 <jeff> #info jeff = Jeff Godin, Traverse Area District Library (TADL) 14:05:48 <bshum> #info bshum = Ben Shum, Bibliomation 14:06:08 <senator> any new arrivals please feel free to announce yourselves 14:06:15 <senator> #topic Action items from the last meeting 14:06:25 <berick> #info berick Bill Erickson ESI 14:06:33 <paxed> #info paxed = Pasi Kallinen, Regional Library of Joensuu 14:06:48 <senator> #info 1. gmcharlt was to cut opensrf 2.2.1 14:07:27 <senator> i can see it didn't happen, and there was probably a reason (as if the guy's full calendar wasn't reason enough) 14:07:35 <ldwhalen> #info ldwhalen = Liam Whalen, Sitka 14:07:39 <senator> does anybody know a blocker on the release or any special reason it didn't happen yet? 14:08:01 <eeevil> not aware of any blockers, but I'm glad that the signal handling stuff might get in 14:08:05 <eeevil> berick++ 14:08:13 * berick finished the code today, in fact 14:08:18 <berick> still need to update LP 14:08:56 <senator> got it 14:09:18 <senator> #action gmcharlt to release opensrf 2.2.1 soon(?) post-vacation 14:09:35 <senator> #info 2. berick and eeevil to release 2.3.9 and 2.4.1 14:09:42 <senator> ok obviously that happened, and more 14:09:58 <senator> 2.3.10 is even released 14:09:59 <eeevil> yep. waiting on eyes for 2.4.2 14:10:19 <senator> 2.4.2 just wants a thumbs up from a tester? 14:10:25 <eeevil> senator: aye 14:10:44 <senator> anybody want to volunteer to verify basic functionality of the 2.4.2 rc? installs without explosions? 14:10:52 <eeevil> I'm relatively happy with it, but that only goes as far as any of you can throw me 14:10:54 * csharp raises hand 14:11:00 <eeevil> csharp++ 14:11:10 <csharp> yeah - I'll whip up a vm directly 14:11:12 <senator> @action csharp to test 2.4.2 rc so we can officialize it 14:11:12 * pinesol_green csharp to test 2.4.2 rc so we can officialize it 14:11:15 <senator> csharp++ 14:11:24 <senator> whoops 14:11:28 <senator> #action csharp to test 2.4.2 rc so we can officialize it 14:11:33 <senator> that's what i meant to type 14:11:34 <senator> ok, 14:11:40 <Dyrcona> heh. too many bots. ;) 14:11:55 <bshum> Well, it's just one bot with many command actions 14:12:07 <csharp> overloaded_bots-- 14:12:09 <senator> ah, excuse me folks, as a newb meeting runner i think i'm repeating the last time's previous action items 14:12:09 <csharp> heh 14:12:37 <senator> moving on to next agenda points then 14:12:39 <bshum> senator++ #taking the lead 14:12:44 <csharp> senator++ 14:13:06 <senator> #info last meeting's actual action items: 14:13:14 <senator> #info 1. start on 2.6 dev road map 14:13:15 <senator> status? 14:13:48 <bshum> Doesn't look like that's started yet. 14:13:50 <senator> no action from me on this item :-( 14:13:51 <senator> yeah 14:14:14 <senator> kudos for dbwells for really staying on top of the 2.5 process, btw. that'll be a hard act for someone to follwo 14:14:22 <senator> dbwells++ 14:14:22 <csharp> dbwells++ 14:14:40 <senator> #info 2. bshum to summarize bug tracking based on feedback from developers 14:15:05 <bshum> Still incomplete at this time. I've been juggling a few too many things and that slipped. 14:15:20 <senator> i hear that 14:15:31 <bshum> I've been thinking about incorporating that into some new how to submit bugs page in the nextgen website. 14:15:33 <bshum> At some point. 14:15:47 <senator> are there linkable scraps of material at this point that we could note for reference? 14:15:53 <Dyrcona> Shouldn't these action items be on the agenda for this meeting? 14:16:04 <kmlussier> senator: I think you had the first set of action items right. These are the action items from the June meeting. 14:16:14 <senator> ha, ok 14:16:20 <senator> you guys are right 14:16:51 <senator> #info the first set of previous meeting's action items were the right ones 14:16:56 <senator> next, 14:17:00 <kmlussier> senator++ 14:17:03 <Dyrcona> If they've not been completed, though, they should probably be moved forward. 14:17:13 <Dyrcona> senator++ 14:17:40 <senator> #action senator to find old incomplete action items to move forward (with help from the channel in making sure i get the right ones) ;-) 14:17:50 <senator> #info gsoc reports 14:17:59 <senator> ^-- how bout that? 14:18:21 <eeevil> senator++ :) 14:19:04 <Dyrcona> Well, our student has disappeared again. 14:19:16 <senator> no reappearance or other good news eh 14:19:26 <bshum> We'll have to figure out what happened and what steps to take next. 14:19:29 <senator> bummer :-( 14:19:43 <eeevil> student's been failed, I assume? 14:20:06 <Dyrcona> Well, he disappeared right after the evaluation. 14:20:16 <senator> the midterm one? 14:20:17 <eeevil> the midterm? 14:20:25 <Dyrcona> yes 14:21:17 <senator> #info student missing, doesn't look good 14:21:22 <dbwells> Is there a branch somewhere of whatever he had done for midterms? 14:21:45 <Dyrcona> Yes, there is. 14:21:57 <bshum> http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dmitriye/dashboard 14:22:19 <senator> #info see IRC logs for this date for link to work done before midterms 14:22:25 <dbwells> bshum: cool, thanks 14:23:02 <senator> so we'll skip release info 14:23:05 <senator> having already talked about that? 14:23:11 <senator> #info qa topics 14:23:21 <senator> phasefx: do you want to pose your question? 14:23:34 <phasefx> some of what I was thinking may be impacted by the next agenda item, but in general... 14:23:50 <phasefx> I wanted to see if we want to start writing pgTAP tests whenever we write db upgrade scripts 14:23:55 <senator> #topic qa topics 14:24:06 <phasefx> there are some good examples committed to master 14:24:06 <senator> (just a correction of my meetingbot stuff, don't mind me) 14:24:52 <phasefx> could start easy, make it a recommendation instead of a requirement 14:25:29 <phasefx> thoughts? need more to time to mull it over? 14:25:40 <eeevil> phasefx: I'll commit (heh) to providing pgtap tests with my changes to the db 14:25:46 <phasefx> eeevil++ 14:25:53 <bshum> It's an interesting idea, I know I'd like some handholding to learn the ropes. 14:26:02 * phasefx can hold hands 14:26:13 <jeff> +1 to more tests 14:26:47 <jeff> phasefx: do you have any useful pointers for starters, and what's your preference on people seeking hand-holding -- irc, mailing list? 14:27:17 <phasefx> jeff: I think looking at the tests in http://git.evergreen-ils.org/?p=Evergreen.git;a=tree;f=Open-ILS/src/sql/Pg/t;hb=HEAD is a good start 14:27:39 <phasefx> also the launchpad bug: https://bugs.launchpad.net/evergreen/+bug/1194246 14:27:39 <pinesol_green> Launchpad bug 1194246 in Evergreen "pgTAP examples" (affected: 1, heat: 6) [Wishlist,Fix committed] 14:27:47 <jeff> phasefx: thanks! 14:27:49 <berick> +1 to easing into it 14:27:54 <phasefx> that shows how to install pgTAP, run the tests, etc. 14:28:24 * phasefx isn't oppossed to IRC, but is more available more often through mailing list 14:28:31 <eeevil> phasefx: is there a TechRef doc in the repo? if not, I'll take that commit message and make one 14:29:08 <phasefx> no, I don't think so 14:29:30 <phasefx> eeevil++ 14:29:39 <senator> #info general interest in easing into qa practices demonstrated by phasefx, phasefx to hold hands with everyone, especially through the mailing list 14:30:02 <senator> #action eeevil to commit a techref doc 14:30:15 <senator> eeevil: like an example techref? 14:30:30 <senator> i actually think there are some, or do you mean something else? 14:30:45 <eeevil> senator: yessir. make those instructions more visible than in a fix-committed LP bug or commit message 14:31:05 <eeevil> I meant a pgTAP techref specifically 14:31:12 <senator> oh a techref about testing itself 14:31:13 <senator> right right 14:31:14 <senator> gotcha 14:31:30 <senator> ok, 30 seconds or so till next topic, unless more talk comes 14:31:45 <phasefx> thanks guys 14:32:03 <senator> #topic db maintenance plan 14:32:09 <senator> eeevil: this part's yours i believe 14:32:18 <eeevil> aye 14:32:20 <kmlussier> phasefx++ #handholding 14:32:58 <eeevil> so, I proposed the following a couple years ago: Carve the baseline SQL schema files in stone at major releases and using change-specific upgrade scripts to roll forward to a given, known-good state at minor version and revision upgrades. 14:33:30 <eeevil> it didn't get much traction at the time, but I think dbs re-{invented|proposed} it about a year ago. 14:33:55 <eeevil> what I didn't list on the agenda are the drawbacks 14:34:30 <eeevil> specifically, that it increases the effort of major-version release managers, as they would be tasked with either doing or leading the reification of the schema 14:35:03 <phasefx> pgTAP tests could help with that 14:35:23 <dbwells> I am not positive I understand, so let me try. In practice, this means a change to the DB involves only creating the upgrade script part, not editing the base files? 14:35:24 <eeevil> however, we've seen enough instances of inter-version drift and mismatching of schema and upgrade scripts that I still think the benefits would far outweigh the extra effort 14:35:40 <Dyrcona> eeevil: Do your plans include any changes to the way that upgrades are done in master? 14:35:45 <eeevil> dbwells: yes, exactly 14:36:38 <eeevil> Dyrcona: no. master would get a reified schema at the same time as the hypothetical 3.0, I think 14:36:50 <eeevil> in fact, it would be a master commit that reifies for 3.0 14:36:56 <eeevil> or, that's how it goes in my head 14:37:15 <Dyrcona> eeevil: My main concern is about the numbered upgrade scripts. Do they stay? 14:37:19 <eeevil> yes 14:37:32 <eeevil> they become /the/ way to make changes to the schema 14:37:42 <Dyrcona> OK. Maybe I wasn't completely understanding either. 14:37:43 <senator> eeevil: to clarify, s/hypothetical 3.0/next major release/ ? 14:37:43 <jeff> eeevil: how would the reification step work? 14:37:46 <Dyrcona> Ah, gotcha. 14:37:48 <senator> (after 2.5) 14:38:13 <phasefx> so no more consolidation of numbered upgrade scripts into version-to-version scripts 14:38:17 <phasefx> ? 14:38:29 <eeevil> the simplest way would be to install master, upgrade it, dumpt the schema and stamp that 14:39:02 <eeevil> phasefx: exactly. we'd be better off polishing one of the various upgrade_db shell scripts that looks at config.upgrade_log 14:39:18 <Dyrcona> I have one in perl. 14:39:22 <dbwells> It does sound like an overall win to me, or at least worth a try. 14:39:34 <eeevil> and, once we settle on one of them (there are at least 4 that I'm aware of in current use) then we can add deprecate/supercede functionality 14:39:52 <csharp> that sounds like exactly what I've wanted for a couple of years now 14:40:02 <eeevil> csharp: you and me both :) 14:40:04 <Dyrcona> I like the idea. It sounds like it will make upgrades over multiple releases easier. 14:40:13 <csharp> Dyrcona: exactly 14:40:16 <eeevil> Dyrcona: that's the intention 14:40:42 <senator> what's the action item for eeevil then? 14:41:01 <csharp> action: FIX ALL THE DB 14:41:01 <eeevil> so! we could actually start as soon as 2.5 if we accept that the baseline schema is what we want to lock in 14:41:28 <dbwells> One other drawback I can see would be grepping/gacking through the schema to find for instance, a certain function. You'd have to sort out the new from the old in the upgrade pile. It wouldn't be that bad, but not as simple and definitive as looking in the 'base' files. 14:41:38 <eeevil> senator: I don't know that there is one ... I guess it would be "flesh out plan and tools for locked major-version schema" 14:41:46 <senator> i hear general positivity but get the idea that people want a chance to digest som more... 14:41:57 <senator> yeah, how bout this 14:42:04 <jeff> would seed data and such be included in the baseline carved at release time? 14:42:25 * csharp would like seed data to become optional fwiw 14:42:44 <senator> #action eeevil to put a more detailed plan on the mailing list to structure further discussion of pros and cons 14:42:46 <csharp> or at least have a --no-seed-data option 14:42:54 <eeevil> dbwells: the thing is that, the situation today where you want to do that is when the baseline is out of whack with the upgrade scripts. in that case, having 2 "authoritative" places to look is worse, IMO 14:43:08 <senator> ^-- how about that action item to keep the meeting rolling? 14:43:19 <jeff> csharp: i'm not sure that all seed data is optional. that said, there could probably be "schema" and "seed data" in stone. 14:43:24 <dbwells> eeevil: but that isn't /supposed/ to happen :) 14:43:31 <eeevil> senator++ # but, yes, seed data would be locked+upgrade 14:43:38 <eeevil> dbwells: exactly :) 14:43:44 <csharp> jeff: yeah - I'm just dreaming big again, but one thing at a time ;-) 14:43:45 <jeff> +1 to that action item 14:43:50 <berick> +1 to action item 14:43:56 <phasefx> +1 14:44:00 <csharp> +1 14:44:09 <senator> you folks are swell 14:44:11 <dbwells> +1 14:44:15 <senator> #topic hack-a-way 2013 plans 14:45:19 <dbwells> #info There are a total of 14 attendees + 2 from Calvin. 14:45:19 <senator> dbwells: unless you have a list handy that you can post of attendees, do we at least want the attendees who are here now to speak up and identify themselves? 14:45:33 * csharp is attending 14:45:33 <senator> ah excellent 14:45:44 * Dyrcona is attending. 14:45:47 * RoganH is attending. 14:45:48 * senator is attending 14:45:50 <dbwells> Yeah, I am not really comfortable just announcing everyone without asking, but please speak up. 14:45:50 * berick too 14:45:53 * kmlussier is attending 14:45:55 * bshum is attending. 14:45:56 * jeff is attending 14:45:57 * jeffdavis is attending 14:46:13 <senator> i'll wait a second for more /me's to roll in, and then i'll put them into one big #info 14:46:29 <kmlussier> He's not here, but I know DPearl is attending. I'm sure he won't mind my saying so. 14:46:35 <phasefx> any notion of telepresence beyond IRC? 14:46:52 <berick> how about a wiki page (like the 2012 page) where we have a voluntary list of attendees and a separate agenda items section? 14:46:56 <senator> phasefx: do you have one of these? http://en.memory-alpha.org/wiki/Holo-communicator 14:47:06 <phasefx> I have three 14:47:13 <senator> sweet 14:47:14 * csharp believes phasefx 14:47:29 <phasefx> one from star wars, star trek, and spaceballs 14:47:30 <eeevil> phasefx: gimme one, man 14:47:31 <dbwells> phasefx: if you could beam one to Calvin, I can get it wired up 14:47:36 <eeevil> ha! 14:47:37 <csharp> ha 14:48:00 * berick offers http://evergreen-ils.org/dokuwiki/doku.php?id=dev:hackfest:hackaway-2013 14:48:08 <RoganH> I might be convinced to run a hangout with a camera. 14:48:16 <dbwells> berick++ thanks 14:48:16 <bshum> berick++ 14:48:17 <phasefx> RoganH++ 14:48:20 <csharp> berick++ 14:48:23 <csharp> RoganH++ 14:48:26 <senator> berick++ keeping us grounded 14:48:34 <senator> RoganH++ 14:49:03 <senator> #info voluntary self-publication of attendee names here: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:hackfest:hackaway-2013 14:49:20 <bshum> At the DIG hackaway, we used a projector and multiple camera sources to help give some illusion of group sense. Though one speaker/mic to avoid noise issues with G+ hangout. 14:49:39 <senator> (better that i skip that #info of names then, so there's just one source of this information - berick's wiki page) 14:49:52 <eeevil> RoganH++ 14:50:09 <bshum> But we'll have to keep at it. We tried that at last year's hackaway too and jeff was always far distant 14:50:51 <jeff> I did the hangout thing for a little bit, but we used a conference bridge / speaker phone for one topic. 14:50:56 <eeevil> bshum: I'm much more obnoxious than jeff ... I'll just yell over all y'all 14:51:45 <bshum> eeevil++ :) 14:51:48 <senator> #info bshum and RoganH have the ideas and recent experience for running a G+ hangout for this kind of event 14:51:57 <senator> anything else? 14:52:14 <senator> bshum: anything i ought to mention before calling endmeeting? 14:52:41 <bshum> I'm cool. 14:52:43 <dbwells> I'll give a quick 2.5 update. 14:52:53 <ldwhalen> senator: I have a question about the authorsort functionality 14:53:21 <dbwells> #topic 2.5 release update 14:53:24 <senator> ldwhalen: cool, but maybe post-meeting for that? 14:53:52 <senator> (which should only be a moment from now anyway) 14:54:07 <senator> dbwells: please do 14:54:23 <ldwhalen> senator: sorry it is more of a policy descion on how to handle pubdates in 008 that are coded with spaces. 14:54:33 <dbwells> I just received credentials for the eg web server, so I'll be uploading an alpha2 tarball soon. 14:55:04 <dbwells> When that is done, I'll send out an overall update about how things stand, and the schedule ahead. 14:55:29 <dbwells> As a preview, I think this is pretty interesting: 14:55:50 <dbwells> for m1: 35 branches merged 14:56:06 <dbwells> m2: 40, alpha1: 30, alpha2: 35 14:56:32 <dbwells> So, a total of 140 branches in 2.5 so far. Thanks to all for what you have been able to contribute. 14:56:42 * senator slow claps 14:56:56 <phasefx> evergreen++ 14:57:12 <dbwells> Despite the shorter time period for the alphas, the work output has been consistent. 14:57:43 <dbwells> I think that is encouraging, but we will need to keep it up a bit longer to get 2.5 out the door. 14:58:00 <dbwells> That's all, thanks again. 14:58:06 <jeff> dbwells++ 14:58:07 <csharp> dbwells++ 14:58:08 <eeevil> dbwells++ 14:58:17 <Dyrcona> dbwells++ 14:58:19 <kmlussier> dbwells++ 14:58:21 <bshum> dbwells++ 14:58:23 <senator> dbwells++ 14:58:27 <senator> #endmeeting