14:02:01 <gmcharlt> #startmeeting November 12, 2013 developer meeting
14:02:02 <pinesol_green> Meeting started Tue Nov 12 14:02:01 2013 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:02 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:02:02 <pinesol_green> The meeting name has been set to 'november_12__2013_developer_meeting'
14:02:09 <gmcharlt> #info Agenda is http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2013-11-12
14:02:23 <gmcharlt> #info gmcharlt = Galen Charlton, Equinox
14:02:28 <csharp> #info csharp = Chris Sharp, GPLS
14:02:40 <jeffdavis> #info jeffdavis = Jeff Davis, Sitka
14:02:42 <Dyrcona> #info Dyrcona = Jason Stephenson, MVLC
14:02:45 <bshum> #info bshum = Ben Shum, Bibliomation
14:02:49 <kmlussier> #info kmlussier = Kathy Lussier, MassLNC (mostly lurking today)
14:02:57 <senator> #info senator = Lebbeous Fogle-Weekley, Equinox
14:02:57 <DPearl> #info DPearl = Dan Pearl, C/W MARS
14:03:01 <jeff> #info jeff = Jeff Godin, Traverse Area District Library (TADL)
14:03:02 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College)
14:03:03 <remingtron> #info remingtron = Remington Steed, Hekman Library (Calvin College)
14:03:10 <phasefx2> #info phasefx2 = Jason Etheridge, ESI
14:03:31 <berick> #info berick Bill Erickson, ESI
14:04:08 <ldwhalen> #info ldwhalen = Liam Whalen, Sitka
14:04:52 <gmcharlt> #topic Action items from last meeting
14:05:12 <gmcharlt> looks like the bug tracking summary is to be deferred to next time
14:05:37 <gmcharlt> and we have pending brain-dump doc-writing from eeevil re pgTAP and schema updates
14:05:46 <gmcharlt> bshum: eeevil: anything more to say before we move on?
14:06:22 <bshum> gmcharlt: Unfortunately nothing new from me.  Though I'll keep trying to put into words our ever evolving methods with Launchpad
14:06:28 <bshum> For the next time
14:06:44 <gmcharlt> ok
14:06:49 <gmcharlt> moving on
14:06:54 <gmcharlt> #topics OpenSRF release
14:07:01 <gmcharlt> #info OpenSRF 2.2.1 was released
14:07:07 <bshum> gmcharlt++
14:07:12 <gmcharlt> #action gmcharlt needs to cut OpenSRF 2.3-beta already
14:07:55 <gmcharlt> anything else re OpenSRF before we move on?
14:07:58 <dbwells> gmcharlt: can you give a brief description of changes for 2.3?
14:08:27 <gmcharlt> dbwells: briefly, a new control script and more options for using signals to control OpenSRF processes
14:08:59 <dbwells> gmcharlt: thanks for the reminder
14:09:28 <gmcharlt> #topic Evergreen releases
14:09:37 <gmcharlt> #info Evergreen 2.5.0 is out!
14:09:39 <jeff> dbwells++ # 2.5 release :-)
14:09:39 <gmcharlt> dbwells++
14:09:50 <csharp> dbwells++
14:09:52 <berick> dbwells++
14:09:53 <phasefx_> dbwells++
14:09:53 <berick> yay
14:09:54 <bshum> dbwells++ indeed!
14:10:02 <dbwells> yay indeed!
14:10:42 <berick> 2.3.next will be cut at the usual monthly time
14:10:43 <kmlussier> dbwells++
14:10:45 <DPearl> dbwells++
14:11:25 <bshum> berick: Related, there's just a few hanging 2.3 backports to go.  If we put those in, maybe this is the last 2.3?
14:11:34 <bshum> (unless there's more security fixing)
14:12:28 <berick> oh, right, we're almost EOL for 2.3
14:12:35 <dbwells> berick: I did mention 2.3 being phased out in the 2.5 email, but tried to leave the door open for whatever you want to do with that timing-wise
14:13:04 <berick> i'll review the pending backports and see what's what
14:13:58 <dbwells> berick: I also left it as "Stable" on the downloads page, so that will need to be changed at some point as well.
14:15:22 <gmcharlt> anything more to say about 2.3 or 2.4?
14:15:36 <berick> dbwells: *nod* and thanks
14:16:19 <gmcharlt> ok, moving on
14:16:25 <gmcharlt> #topic Releae manager for 2.6
14:17:09 <Dyrcona> I put the new business items on the agenda, because I know that two of them are things we need to talk about/vote on.
14:18:03 <Dyrcona> dbwells sent an email to the dev list this morning where he basically volunteered to be RM for 2.6.
14:19:48 <remingtron> jos
14:19:48 * berick wonders why he's not seeing this email
14:19:52 <berick> to the archives
14:19:55 <remingtron> sorry, wrong window
14:20:50 <gmcharlt> #link http://libmail.georgialibraries.org/pipermail/open-ils-dev/2013-November/009149.html
14:20:52 <dbwells> I hope people got a chance to read it, but what Dyrcona said is a reasonable 20 word or less summary of my ~300 words :)
14:21:57 <bshum> Slightly better formatting: http://markmail.org/message/54ffdrtc2ofc6qjo
14:23:16 <berick> while we're all here, does anyone else plan to throw a hat in the ring?
14:23:27 <gmcharlt> from my POV, while I support dbwells as RM for 2.6, voting the same day as the proposal seems rushed -- I propose that we give a week, then assent via email if no other proposal is made
14:23:42 <berick> +1
14:23:44 <phasefx2> +1
14:23:47 <jeff> +1
14:23:48 <Dyrcona> +1
14:24:17 <csharp> I think I made the point at the Hackaway that we are pretty much at the point where we have exhausted the pool of available/qualified/willing candidates ;)
14:24:34 <csharp> +1
14:24:44 <kmlussier> +1
14:24:49 <DPearl> +1
14:24:57 <dbwells> I can also flesh out a proposal if people really want it, but my cliff notes version would be, "More of the same, but faster!"
14:25:06 <csharp> dbwells++
14:25:08 <jeff> dbwells++
14:25:29 <Dyrcona> dbwells++
14:25:30 <phasefx2> "We have the technology"
14:25:35 <gmcharlt> indeed we do
14:25:43 <gmcharlt> OK, so moving on
14:26:08 <gmcharlt> #topic Proposal: make 2.6 a stability release and putting new development into 3.0
14:26:14 <gmcharlt> Dyrcona: the floor is yours
14:26:48 <Dyrcona> This comes out of something dbwells mentioned in his email, about the next release being compressed into 4 months.
14:27:00 <Dyrcona> When I thought about it, that doesn't seem like a lot of time.
14:27:40 <Dyrcona> It seems to me, too, that we do have some trouble hitting our feature release very 6 months deadlines.
14:28:15 <Dyrcona> I don't think that is the fault of the release manager. I think our resource pool is just too small and most have other responsibilities.
14:28:45 <Dyrcona> What I am proposing is that whatever new features are ready by the deadline, go into 2.6.
14:28:46 <kmlussier> Dyrcona: With this proposal, are you saying any new development done over the next two or three months would need to wait until a Fall 2014 release?
14:29:04 <Dyrcona> Um, no, but our messages crossed. :)
14:29:24 <kmlussier> Dyrcona: Sorry. I spoke too quickly. Continue. :)
14:29:27 <berick> oohhh
14:29:35 <berick> i had the same confusion
14:29:36 <Dyrcona> After that, I think 2.6 should be frozen and maintained for bug fixes for some unknown amount of time.
14:30:10 <Dyrcona> I think a 3.0 branch could be cut or master used for new feature development.
14:30:28 <Dyrcona> And here, I'm talking big things, like the web-only staff client, etc.
14:30:34 <bshum> New like web-base... yeah
14:30:50 <Dyrcona> That would be released when the list of features are ready.
14:30:52 <eeevil> Dyrcona: and would 3.0 be delayed for some currently-unspecified amount of time?
14:30:55 <berick> Dyrcona: you're kind of describing the way I thought things already worked (in theory).
14:31:32 <dbwells> So the big change is that 3.0 becomes unscheduled?
14:31:34 <Dyrcona> eeevil: yes. For these two releases, we'd be abandoning the "current" release schedule, that I don't think is working, but I could be wrong.
14:31:34 <eeevil> ok, so, make 2.6 the last timed release until 3.0, which might be 12, 18 or 24 months out
14:31:54 <Dyrcona> Basically, yes.
14:32:36 <eeevil> the problem with that, that time releases are supposed to address, is that new features will take forever to appear
14:32:41 <csharp> I think we're more like Fedora, where we're scheduling every six months but accept delays
14:32:49 <eeevil> instead of only being delayed by one cycle at most
14:32:52 <csharp> rather than Ubuntu's clockwork thing ;-)
14:32:55 <jeff> Dyrcona: you mentioned Linux 2.6 vs 3.0. was that just that the numbering happened to coincide, or is there a practice you're thinking of patterning this after?
14:33:47 <eeevil> or, that's my understanding of (one of the) motivations of timed releases
14:33:51 <Dyrcona> jeff: Just because the numbering happened to coincide. The linux 2.6/3.0 is a bit different.
14:34:36 <jeff> Dyrcona: got it. thanks for clearing up my misunderstanding. :-)
14:34:57 <Dyrcona> Also, when I said "stable" I mean a stable feature set. Not what most people think of when they say "stable."
14:35:23 <csharp> if 2.6 remains a stable code base, back porting new features should be doable, right?
14:35:28 <eeevil> isn't that the case now? 2.5 won't get any new features, but will get bug fixes for 15 months...
14:35:29 <dbs> #info dbs = Dan Scott, Laurentian University (LATE)
14:35:43 <jeff> The big downside that I see is new features stop for an unknown amount of time unless you're running pre-release in production. What do you see as the advantages?
14:35:47 <csharp> or is that the point - 2.6 stays "new-feature-free"?
14:35:57 <eeevil> #info eeevil = Mike Rylander, ESI (also late)
14:36:06 <jeff> csharp: depends on if the backported bits rely on larger underlying changes.
14:36:09 <Dyrcona> eeevil: To be frank, I'm not sure we have the community to support new features every 6 months.
14:37:18 <eeevil> Dyrcona: now /that/ I agree with. I think a 12mo cycle is more our speed if we stay timed. but that still keeps new features out of folks hands for a long time
14:37:58 <eeevil> the other end of the spectrum is constant release, with some marked with a version number and tar'd up for download
14:38:01 <Dyrcona> eeevil: At the risk of burning a lot of karma, I think "the folks" are a part of the problem.
14:38:25 <eeevil> Dyrcona: "the folks" are the libraries using evergreen... so...
14:38:45 <Dyrcona> What I hear from the "community" is that they want the features, like yesterday, but they don't want bugs, and then they systematically stay 2 releases behind.
14:39:02 * berick wonders what features are taking 8 months to develop
14:39:22 <Dyrcona> Everything that went into 2.5.
14:39:36 <eeevil> berick: full authority browse was one (though not 8mo of constant typing)
14:40:11 <dbs> Well, not every place is 2 releases behind, and not every feature takes longer than 6 months
14:40:31 <RoganH> #info RoganH = Rogan Hamby, SCLENDS
14:40:40 <Dyrcona> Of course I'm generalizing. Who has time for specifics in IRC?
14:40:42 <berick> so the problem is that releases go into master before they are release ready?
14:40:48 <RoganH> Not everyone is 2 behind but for example in SCLENDS my directors have demanded to be one release behind to avoid bugs.
14:40:48 <Dyrcona> No.
14:40:50 <berick> and thus delay the release?
14:41:10 <bshum> So specific.... and stop me if I'm asking a stupid question.
14:41:12 <eeevil> dbs: absolutely. I'm still enamored of "stamp arbitrary way-points as releases"
14:41:15 <jeff> Dyrcona: I'm not sure I understand the advantage to what you're proposing. Is the idea to give a supported release to those libraries that currently are upgrade-averse, so that they're not running "unsupported"?
14:41:31 <bshum> Of particular concern to me is our transition to using web based clients, as we've discussed, and have prototypes underway and such.
14:41:47 <dbwells> 2.4 was released on May 3, and 2.5 on Nov. 8, so that's 6 months and 5 days for 2.5.  (but who's counting? :P)
14:41:51 <dbs> TPAC evolved over a number of releases to eventually replace JSPAC, I think that's a good example of something that took > 6 months to develop, and did so iteratively
14:41:54 * gmcharlt observes that the web-based client is *not* an all-or-nothing thing
14:41:58 <bshum> Do we expect there to be new features built on top of our existing xul/dojo infrasture that also need to be ported into the web client?
14:42:03 <berick> dbs++
14:42:17 <jeff> Dyrcona: apologies, because I've so far misunderstood a few aspects of the propsal, but how would the proposed 3.0 differ from master today?
14:42:53 <Dyrcona> jeff: I haven't worked out all of the details. I wanted to throw this out there as something to discuss.
14:42:58 <eeevil> and to be fair, the same happened with bib browse. the bib part came first, and the authority part later ... they just happened to drop in the same release
14:43:01 <rfrasur> #info rfrasur = Ruth Frasur, Evergreen Indiana
14:43:30 <bshum> gmcharlt: Fair enough.
14:43:38 <eeevil> bshum: that will, with out a doubt, have to happen to some degree, IMO
14:44:09 <eeevil> bshum: until there is actual momentum on web-based, AND coverage of the more complicated staff UIs
14:44:54 <bshum> To me, that's something that could happen with a freeze at 2.6 ending xul/dojo work and letting us focus on a transition to other things in 3.0 without having to split all of our focuses.  But maybe I'm not thinking big enough.
14:45:43 <eeevil> we all agree that pretty much everything can be developed itteratively
14:45:45 <jeff> Another approach would be to freeze some staff interfaces as web interfaces mature, and not tie it to an entirely feature-frozen release.
14:46:16 <eeevil> and some plurality of us content that 6mo is short for our dev resources
14:47:01 <gmcharlt> and a plurality (?) not particularly desirous of an indefinite schedule
14:47:10 * berick still does not understand how 6mo is short
14:47:28 <eeevil> (s/content/conted/) and some other, partially overlapping pluratily contends that longer than 6mo is painful to wait for some new features, due to scheduling
14:47:28 <rfrasur> I'd just like to throw in there as one of "the folks" - one reason that it takes so long to move to the new release is that after the features are available, we have to go through a lot of procedural stuff to make sure it works for all our members and basically factor in the human element.  Personally, I'd love to move to 2.5 yesterday, but it's just not feasible when you're dealing with 102/3 libraries with people working
14:47:28 <rfrasur> at them.
14:48:04 <bshum> eeevil: I agree that we can develop iteratively, but people have gotten burned by using those features iteratively by following the latest releases.  I think of all our fun with acq since 2.0 in that sense.
14:48:05 <Dyrcona> rfrasur: I'm aware of that, believe me, I'm aware of that.
14:48:09 * eeevil type good...
14:48:41 <senator> this is definitely more complex than an up/down vote on dyrcona's initial suggestion
14:48:43 <rfrasur> ;), just so you know that it's not that we're breathing down the developer's neck only to walk away and ignore whatever work's been done.
14:48:49 <senator> i think we ought to hash this out on the list
14:48:57 <Dyrcona> Well, may I suggest that we table this or even throw it out the window?
14:49:03 <Dyrcona> senator++
14:49:07 <eeevil> bshum: I can't argue with the counter-example of acq, except to say that that's about as complicated as you can get ... I can't think of another similar example
14:49:35 <csharp> senator: +1
14:49:52 <gmcharlt> #info Discussion of the proposal to be moved to open-ils-dev
14:49:56 <gmcharlt> #topic Requiring automated tests for new code/database modifications.
14:49:59 <eeevil> anyway, my point was, am I alone in seeing the "arbitrary waypoints as versioned releases" as a way around much of this?
14:50:07 <eeevil> and with that, I'll hush
14:50:40 <gmcharlt> eeevil: no, you're not, but that implies some things that we don't have yet but hopefully will accumulate over time
14:50:53 <gmcharlt> that actually was an excellent seque into the current topic :)
14:51:22 <jeff> heh.
14:51:23 <jeff> gmcharlt++
14:51:43 <Dyrcona> I put this on the agenda, too.
14:51:47 * Dyrcona ducks.
14:52:20 <Dyrcona> I think dbs email was a call for this to be more formal and eeevil and others have made strides in that direction.
14:52:38 <Dyrcona> This, I hope, we could actually "vote" on.
14:53:24 <dbs> I think we could make pgTAP tests for database changes a matter of policy. Not sure if we're ready for requiring tests for general code modifications though
14:54:11 <jeff> I think that all-or-nothing "no commits without matching unit tests" is impractical given our current testing infrastructure. Starting with database changes where we have pgTAP seems like a good beginning.
14:54:37 <jeff> "Encouraged" elsewhere, and we can transition to "required" as our testing methodologies mature.
14:54:42 <dbs> FWIW, I thought August's dev meeting had already voted on the pgTAP test requirement?
14:54:46 <dbs> jeff++
14:55:02 <Dyrcona> Was that a vote on a requirement?
14:55:12 * phasefx2 thought that was an "ease into it"
14:56:01 <dbs> phasefx2 is right
14:56:08 <dbs> http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-08-27-14.04.log.html
14:56:35 <RoganH> As someone who handles contracts for development rather than development myself I wish it was a requirement.  When I get competing bids and vendor X says we can cut costs for you by not doing tests that seems attractive to some of my members - the same ones who complain about unexpected behavior of course but still.
14:57:21 <Dyrcona> As a developer, I'd have to learn to do the tests...
14:57:55 <Dyrcona> I think the rumblings are that devs in general would like to see these be required.
14:58:00 <jeff> browsing "git log -- Open-ILS/src/sql/Pg/upgrade", i don't know if i can say without a doubt that every recent change immediately lends itself to having a unit test.
14:58:33 <gmcharlt> #startvote Shall pgTAP test cases (where applicable) be required for new commits starting with 2.6? Yes, No, Postpone
14:58:33 <pinesol_green> Begin voting on: Shall pgTAP test cases (where applicable) be required for new commits starting with 2.6? Valid vote options are Yes, No, Postpone.
14:58:33 <pinesol_green> Vote using '#vote OPTION'. Only your last vote counts.
14:59:02 <phasefx2> #vote Yes
14:59:21 <berick> gmcharlt: to clarify, 2.6 means staring now w/ all new features?
14:59:23 <jeff> Is this meaningless if we don't have a good idea of what "where applicable" means?
14:59:29 <eeevil> jeff: not all do. I'm fine with being called out when I don't add one that could
14:59:29 <bshum> "where applicable" is vague enough that given my general infamiliarity with pgTAP use, I'm not sure I'm ready to commit to that.
14:59:33 <phasefx2> you can make an assertion about any upgrade script; at the very least, it might help someone check that they actually ran a required upgrade script
14:59:52 <RoganH> #vote Yes
14:59:59 <phasefx2> but coming up with mock environments to test behavior for stored procedures.. that might be a bit much for some folks
15:00:01 <bshum> But I'm among the "have to learn to do the tests..." folks
15:00:14 <gmcharlt> berick: yes -- though the RM may have the option to exercise discretion
15:00:19 <berick> thanks
15:00:32 <berick> #vote YES
15:00:33 <phasefx2> if doing an independent unit test as oppossed to relying on concerto test data
15:00:34 <eeevil> gmcharlt: s/may/should/ IMO
15:00:36 <berick> tis inevitable
15:00:54 <gmcharlt> bshum: in my view, a requirement will encourage folks to learn the framework
15:01:03 <gmcharlt> eeevil: agreed
15:01:30 <gmcharlt> #vote Yes
15:01:34 <dbwells> #vote Yes
15:01:42 <eeevil> #vote yes
15:02:00 <dbwells> I am anxious to see how this will play out in practice, but it certainly can't hurt to try.
15:02:03 <jeffdavis> gmcharlt: or conversely, folks who might otherwise contribute a patch might decide it's too difficult
15:02:18 <jeffdavis> (not that I'm opposed to unit tests)
15:02:34 <gmcharlt> jeffdavis: the requirement applies to the commit, not the person, IMO
15:02:35 <eeevil> dbwells: in practice, you'll get to threaten revert unless a test shows up :)
15:03:02 <gmcharlt> IOW, a more experienced dev helping write unit tests for a patch originated by somebody else would be a Good Thing
15:03:12 <csharp> can buildbot run the tests?
15:03:23 <berick> dbwells: you are this -><- close to be elected benevolent overlord
15:03:28 <csharp> (thinking of pgTAP)
15:03:43 <csharp> berick++
15:03:51 <phasefx2> csharp: ultimately yes
15:04:02 <jeff> If I'm crafting a database upgrade script and base-schema changes to add a new org unit setting type, 1) is that "where applicable" and requires a pgTAP test? and 2) What is tested -- test for successful insertion / existence in config.org_unit_setting_type?
15:04:11 <jeffdavis> which could mean experienced devs spend more time on others' patches, or that those patches languish
15:04:21 <jeffdavis> again, I'm not opposed, but I do worry a bit about the downsides
15:04:47 <eeevil> jeff: that's a case where it seems useless. we have config.upgrade_log for that
15:04:48 <bshum> Not all committers are made equal.  I say this as the timid one of the group here.
15:05:08 <dbs> #vote yes
15:05:15 <bshum> In principle, I agree; I just won't say when I'm ready till I know more.
15:05:18 <bshum> #vote yes
15:05:32 <jeff> jeffdavis: I think that "patches languishing" can be evaluated at a time afterward. If there's an issue, the decision can be re-evaluated or additional steps can be taken to make things easier to test, etc.
15:05:32 <berick> jeff: good question.  imo, seed data that's not used by the DB (only the app) is not really worth the effort of testing in pgtap;  app-level tests, sure.
15:05:33 <dbs> code reviewers will certainly help where needed methinks
15:06:04 <eeevil> also, my as yet unsent plan for non-changing base schema would reduce the overhead of this...
15:06:05 <gmcharlt> and requiring unit tests can help promote more code review
15:06:09 * eeevil --
15:06:20 <phasefx2> jeff: there's also automated test creation for simple things like that, that we may want to think about
15:06:21 <gmcharlt> (and I've seen evidence of that in Koha-land)
15:06:34 <dbs> (For 2.6 I'd kind of like to make good on the threat others have for pulling the fake org_unit stuff out of seed data and into concerto & friends)
15:07:02 <jeff> Okay. Further questions about "where applicable" and such to be sought on open-ils-dev, where you can either find help in conceptualizing / creating a test, or concensus on "not applicable"?
15:07:04 <dbs> (But that's a different subject :) )
15:07:04 <Dyrcona> #vote postpone # cause there's no "abstain" option other than not voting.
15:07:04 <pinesol_green> Dyrcona: postpone # cause there's no "abstain" option other than not voting. is not a valid option. Valid options are Yes, No, Postpone.
15:07:09 <bshum> dbs: +1
15:07:19 <Dyrcona> #vote postpone
15:07:40 <gmcharlt> Dyrcona: because it's your own proposal, or because the parameters I set for the vote don't match what you have in mind?
15:07:44 <csharp> dbs: +1
15:08:28 <Dyrcona> gmcharlt: Because I'm actually ambivalent about the topic.
15:08:43 <Dyrcona> I brought it up because I think we need some official clarity on the matter.
15:09:36 <Dyrcona> Well, what passes for official around here, anyway. :)
15:10:02 <jeff> #vote Yes
15:10:04 <senator> #vote Yes
15:10:04 <dbs> Dyrcona++
15:10:09 <gmcharlt> Dyrcona: you didn't seen the Officail Badge dbwells has been wearing for the past few months?
15:10:41 <gmcharlt> anyway
15:10:43 <gmcharlt> #endvote
15:10:43 <pinesol_green> Voted on "Shall pgTAP test cases (where applicable) be required for new commits starting with 2.6?" Results are
15:10:43 <pinesol_green> Yes (10): jeff, berick, RoganH, dbwells, gmcharlt, bshum, senator, dbs, phasefx2, eeevil
15:10:43 <pinesol_green> Postpone (1): Dyrcona
15:11:08 <gmcharlt> #agreed pgTAP test cases (where applicable) are required for new commits start with 2.6
15:11:16 <phasefx2> yay
15:11:40 <gmcharlt> any other last minute insertions before we end the meeting?
15:12:29 <gmcharlt> ...
15:12:34 <gmcharlt> #endmeeting