15:07:55 <kmlussier> #startmeeting Evergreen Developer Meeting - 2014-07-28
15:07:56 <pinesol_green> Meeting started Mon Jul 28 15:07:55 2014 US/Eastern.  The chair is kmlussier. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:07:56 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:07:56 <pinesol_green> The meeting name has been set to 'evergreen_developer_meeting___2014_07_28'
15:08:14 <jeff> kmlussier++
15:08:17 <bshum> kmlussier++ # just getting back to my desk
15:08:17 <kmlussier> #info Agenda is available at http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2014-07-28
15:08:22 <kmlussier> #topic Introductions
15:08:41 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC
15:08:45 <jeff> #info jeff is Jeff Godin, Traverse Area District Library (TADL)
15:08:45 <eeevil> #info eeevil == Mike Rylander, Equinox Software
15:08:50 <bshum> #info bshum is Ben Shum, Bibliomation
15:08:52 <DPearl1> Dpearl1 is Dan Pearl, C/W MARS Inc.
15:08:53 <Dyrcona> #info Dyrcona is Jason Stephenson, MVLC
15:08:54 <phasefx> #info phasefx = Jason Etheridge @ ESI
15:08:55 <gmcharlt> #info gmcharlt = Galen Charlton, ESI
15:09:05 <dbs> #info dbs is Dan Scott, Laurentian University
15:09:09 <dbwells> #info dbwells is Dan Wells, Hekman Library (Calvin College)
15:09:09 <RoganH> #info RoganH = Rogan Hamby, SCLENDS
15:09:12 <DPearl1> #info Dpearl1 is Dan Pearl, C/W MARS Inc.
15:09:13 <berick> #info berick Bill Erickson, ESI
15:09:18 <ldw> #info ldw = Liam Whalen, Sitka
15:09:18 <phasefx> want to see how many different formats get used for folks introducing themselves :)
15:09:40 <eeevil> phasefx: I'm personally tickled by the assignment version :)
15:10:32 <gmcharlt> OpenSRF/BASIC: LET gmcharlt = Galen Charlton
15:10:46 <RoganH> eeevil: we could see how many types of assigning variables that could be done.  Set Rogan = .....
15:10:50 <kmlussier> OK, people can continue introducing themselves as we move forward.
15:11:07 <kmlussier> #topic Action Items from Last Meeting
15:11:17 <eeevil> REM I like it
15:11:24 <kmlussier> #info dbwells to review and comment on conditional negative balance bug:https://bugs.launchpad.net/evergreen/+bug/1198465
15:11:26 <pinesol_green> Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 14, heat: 62) [Wishlist,Confirmed]
15:11:45 <kmlussier> So dbwells has added code to this bug and also added some comments today.
15:11:54 * kmlussier hasn't had a chance to review the most recent comments.
15:12:42 <dbwells> Yeah, remingtron and I worked on it for a few days right after the last meeting, but haven't heard back, nor gotten back to it ourselves since.
15:13:10 <dbwells> I posted something today just to give it at least *some* small momentum forward :)
15:13:20 <csharp> #info csharp is Chris Sharp, GPLS
15:14:20 <jeff> dbwells++ remingtron++
15:14:21 <kmlussier> As part of this action item and the next one, I haven't had a chance to review the most recent code or pull together my summary. The negative balance was 1 of 4 billing projects MassLNC was working on. We decided a few weeks ago to really focus on the other three so that we can get them out of the way before we get back to negative balances, which is a harder nut to crack.
15:14:30 <jeff> (for rounding up scarce tuits)
15:15:01 <kmlussier> But just glancing at dbwells' most recent comment, it looks like there is still a bit of work to be done before this branch is ready to be merged?
15:15:45 <dbwells> Testing at the very least, but like I mentioned, I think a few hours spent on display side would be time well spent for me.
15:16:41 <kmlussier> dbwells: I'm having a hard time picturing what you suggested in your comment, but I also had some concerns on the display side.
15:18:35 <kmlussier> I also don't think I'll have a chance to test the most recent code until we finish working on our two remaining billing projects. Having two dev branches loaded on the test server at the same time causes confusion over which one might be causing a problem.
15:19:42 <Dyrcona> Well, when they're related to the same part of the system, anyway.
15:21:16 <dbwells> kmlussier: If you have a testing timeline in mind, I can try to work on my display ideas so you can test it at the same time.  Feel free to get in touch after this meeting if needed.
15:21:26 <kmlussier> So I guess we need some kind of action item for me to test the current branch and provide feedback? I don't know if anyone else wants to take a look at it.
15:21:56 <jeff> I've interest but cannot guarantee that I can make time for it in the next month.
15:22:07 <kmlussier> dbwells: Will do. I'll have to consult with Dyrcona regarding a testing timeline, but we can figure it in short order.
15:22:12 <jeff> I'll see what I *can* do, though.
15:22:25 <kmlussier> jeff++ Thanks!
15:22:47 <kmlussier> #action kmlussier and others to make time to test the latest branch.
15:23:09 <kmlussier> #action dbwells to work on display ideas for negative balance branch
15:23:24 <kmlussier> dbwells and remingtron: Thanks for taking a look at it!
15:23:35 <kmlussier> Anything else before we move on?
15:23:39 <jeff> reducing the number of cases where we deviate from stock is a goal, and our own branch to avoid negative balances is ripe for elimination if we can assist in testing this one.
15:23:41 <Dyrcona> dbwells++ remingtron++
15:24:15 <kmlussier> #topic OpenSRF release
15:24:27 <kmlussier> Anything to report one OpenSRF?
15:24:38 <gmcharlt> I'm looking for volunteers to test the websockets work submitted by berick
15:24:44 <gmcharlt> any takers?
15:24:49 <bshum> Further down in the agenda, there's some notes about websockets
15:25:03 <bshum> Sorry, juggling between meetings
15:25:22 <jeff> I can test, assuming berick or others are available for questions when I reach that point.
15:25:27 <berick> anything I can do to make testing easier?
15:25:28 <berick> jeff: yes
15:25:37 <jeff> berick++ thanks!
15:25:42 <eeevil> gmcharlt: re your 3 options, I'm strongly in favor of merging what's there and getting the release out
15:25:59 <gmcharlt> likewise
15:26:07 <gmcharlt> jeff: can you put some testing time into this week?
15:26:10 * csharp can test, but has not had the time lately to keep up with development, so may need assistance ;-)
15:26:26 <jeff> gmcharlt: yes. i was just about to ask what timeline you had in mind.
15:26:31 <kmlussier> berick: How many testers do you need?
15:26:42 <kmlussier> Sorry, that was for gmcharlt.
15:26:50 <gmcharlt> jeff: let's shoot for by the end of this week, if you can
15:27:18 <eeevil> berick: is it true that anyone whose tested your dev on your demo server has tested the websockets code?
15:27:35 <berick> eeevil: they have, indeed
15:27:37 <jeff> gmcharlt: i will shoot for that. thanks!
15:27:59 <gmcharlt> ok
15:28:00 <csharp> then Terran has definitely been testing
15:28:07 <eeevil> csharp: :)
15:28:09 <dbs> They all haven't installed it locally though :)
15:28:14 <kmlussier> So for an action item, that's jeff and csharp? Do we need more testers or is that good?
15:28:25 <gmcharlt> given that, I'm planning on cutting an alpha of OpenSRF the middle of next week
15:28:27 <berick> dbs: exactly.
15:28:28 <bshum> Does the websockets work interact with the current staff client?
15:28:29 <csharp> yeah, I'll install locally
15:29:00 <berick> bshum: it does not interract, but code the staff client uses is touched, like the JS opensrf libs
15:29:02 <bshum> Just making sure that present stuff continues to function I guess over what's coming next too.
15:29:05 <eeevil> bshum: only insofar as its part of opensrf ... the current SC does not attempt to make use of it
15:29:08 <bshum> Okay.
15:29:13 <bshum> So that's something we ought to test as well.
15:29:22 <berick> bshum: definitely
15:29:22 <bshum> To make sure that it doesn't break any existing functionality
15:29:50 <kmlussier> #action jeff and csharp to test websockets work by the end of this week.
15:30:14 <kmlussier> #action gmcharlt to cut alpha of OpenSRF the middle of next week (week of Aug. 4th)
15:30:23 <kmlussier> Anything else on OpenSRF?
15:31:16 <kmlussier> #topic Evergreen maintenance releases
15:31:18 <kmlussier> dbwells?
15:31:56 <dbwells> #info 2.6.2 and 2.5.6 were released on 7/7
15:32:25 <dbwells> I would also like to ask about the next round, which was due last Friday.
15:32:49 <dbwells> There is only one actual code change: https://bugs.launchpad.net/evergreen/+milestone/2.6.3
15:32:49 <pinesol_green> dbwells: Error: malone bug 2 not found
15:33:52 <dbwells> Given the very small number of commits since 2.6.2, do we need a maintenance release now, of just wait until the next cycle?
15:34:04 <eeevil> +1
15:34:24 <bshum> dbwells: +1 to waiting
15:34:40 <dbwells> I am happy to do it if anyone needs it done.
15:34:48 <csharp> +1
15:35:05 <eeevil> only matters if you're on master opensrf, IIRC
15:35:24 <dbwells> That was also my understanding, but wanted to verify that as well.
15:35:36 <eeevil> that's how it bit me, anyway :)
15:36:04 <Dyrcona> And the two of us that use OpenSRF master should have that fix where necessary. :)
15:36:16 <eeevil> but, opensrf 2.4 coming out as a package soon... I guess we'll need a release before that's GA
15:36:17 <kmlussier> dbwells: If we wait until the next cycle then, it's an August 20 release date?
15:36:59 <dbwells> kmlussier: yes
15:37:06 <kmlussier> ok, thanks!
15:37:15 <bshum> dbwells++
15:37:17 <eeevil> gmcharlt: you expect to bundle opensrf 2.4 before then?
15:37:25 <eeevil> August 20, that is
15:37:28 <gmcharlt> eeevil: yes
15:38:08 <Dyrcona> gmcharlt: Would it be a problem to wait?
15:38:29 <eeevil> ah ... well... we'll need to warn folks against using it ("max supported version for evergreen is 2.3"), or cut back branch releases of EG.
15:39:00 <bshum> Traditionally, I don't think we've recommended to people to change OpenSRF versions mid-major release for Evergreen.
15:39:07 <bshum> Meaning Evergreen 2.6 stays with OpenSRF 2.3
15:39:11 <bshum> etc.
15:39:18 <csharp> correct
15:39:19 <gmcharlt> bshum: I'm not sure we've made definite statements, however
15:39:22 <bshum> And when OpenSRF 2.4 is around, we focus that towards Evergreen 2.7
15:39:27 <eeevil> bshum: I don't recall a specific recommendation on upper release boundary
15:39:49 <csharp> I think we should stick with one opensrf version per release, myself
15:39:56 <bshum> It's not explicitedly defined as such and in fact the README would say use the latest all the time I guess...
15:40:00 <eeevil> we've certainly had a "requires at least" statement
15:40:06 <bshum> But the downloads page doesn't get changed as new OpenSRF comes into being
15:40:09 <eeevil> and the install docs usually say "install the latest"
15:40:20 <bshum> So Evergreen 2.5 still points at OpenSRF 2.2
15:40:25 <bshum> While 2.6 points at 2.3
15:40:42 <gmcharlt> as minimum required version
15:40:44 <bshum> So it's sort of implied, but we all know what happens when we assume
15:40:52 <csharp> barring a security concern, I wouldn't upgrade OpenSRF without also upgrading EG
15:41:08 <eeevil> gmcharlt: right ... that doesn't imply a max to me, but a min
15:41:36 <eeevil> csharp: sure, but we're talking about new downloads
15:41:41 <bshum> Well I always read it as "use this exact version of OpenSRF with Evergreen, because beyond here lies dragons" but I guess we all read them differently.
15:41:58 <gmcharlt> circling back to "no definite statement has been made"
15:42:05 <kmlussier> So it sounds like our options are to either to do an earlier point release for 2.6 or explicitly stating that people shouldn't use OpenSRF 2.4 until they are on 2.7.
15:42:14 <csharp> eeevil: I think for troubleshooting purposes, we should have a consistent stack... do you disagree with that?
15:42:17 <eeevil> kmlussier: well, an on-time release ;)
15:42:41 <gmcharlt> bshum: remind me - when would you like to cut the 2.7 beta?
15:42:41 <eeevil> csharp: sure. but new users will grab the latest of each to try it out
15:42:46 <kmlussier> eeevil: Yes, an on-time release. :)
15:42:54 <bshum> gmcharlt: That's something I wanted to have some debate on actually.
15:43:20 <bshum> The scheduled date for 2.7.0 beta freeze and presumably soon thereafter cutting is next Thursday, August 7
15:43:21 <csharp> so we're talking about for testing purposes? or for general usage?
15:43:23 <dbwells> I can be flexible if we want to coordinate OpenSRF 2.4, 2.7-beta, 2.6.3, and 2.5.7 to all roughly coincide for dependency reasons.
15:43:26 <eeevil> dbwells: looks like we there's no rest for the wicked this month ;)
15:43:37 <gmcharlt> well, we can sequence things like this: opensrf 2.4 alpha => EG 2.6 beta => EG 2.5/2.6 pint releases => opensrf 2.4.0
15:43:41 <eeevil> dbwells++
15:44:02 <bshum> If we push it back too far, then I'd be concerned about slippage of dates and getting 2.7.0 released for September.
15:44:11 <eeevil> (s/2.6 beta/2.7 beta)
15:44:17 <bshum> And I was hoping for an on-time delivery.  :)
15:44:55 <gmcharlt> unless I'm missing something with the sequencing... sounds doable
15:45:31 <eeevil> gmcharlt: yeah, that seems fine. specific dates don't matter then
15:45:42 <hopkinsju_> Based on the documentation I would think that setting 'Show evening_phone field on patron registration' true would show the field on the patron self registration form. This doesn't seem to be the case. Am I missing something?
15:46:04 <gmcharlt> hopkinsju: would you mind holding that question till after the meeting finishe?
15:46:17 * hopkinsju apologizes for the interruption
15:46:22 <gmcharlt> no worries
15:46:29 <kmlussier> So if we go with that sequencing, do we need to specify a date range as to when all this happens?
15:46:40 <bshum> Hang on, dates are important (just trying to keep things straight).  gmcharlt, are you saying that you think we can get OpenSRF 2.4 alpha out before the August 7 date for Evergreen 2.7 beta?
15:46:44 <gmcharlt> eeevil: dbwells: bshum: then it sounds like an OpenSRF 2.4.0 by the end of August would be fine for EG 2.7.0
15:46:50 <bshum> And then after that, we line things up for the next round of maintenance releases
15:46:55 <bshum> etc.
15:47:41 <gmcharlt> bshum: yes - "#action gmcharlt to cut alpha of OpenSRF the middle of next week (week of Aug. 4th)"
15:48:09 <bshum> Okay, cool.
15:48:29 <kmlussier> And then we have beta on the 7th and then 2.5 and 2.6 point releases, we're still looking at Aug. 20?
15:48:44 <bshum> That sounds reasonable.
15:48:59 <bshum> The next date for 2.7 after beta is the RC date, which is Sept 4
15:49:09 <dbwells> I'd like to plan the point releases for Aug. 7 as well, if nobody minds.
15:49:11 <bshum> So that gives us time to do tests, etc. with the new OpenSRF
15:50:05 <kmlussier> #agree next round of point releases will be scheduled for August 7
15:50:10 <kmlussier> Anything else before we move on?
15:50:23 <bshum> Just an info
15:50:36 <gmcharlt> er, that would be point releases for August 20, no?
15:50:58 <bshum> Nope, nothing, sorry.  I got all my questions answered now.
15:51:07 <bshum> Just had to read back upward
15:51:16 <kmlussier> gmcharlt: dbwells just said he would like to plan for August 7
15:51:26 <gmcharlt> ah, sorry
15:51:32 <kmlussier> #topic Evergreen 2.7 release
15:51:38 <kmlussier> bshum, you've got the floor
15:52:04 <bshum> Well, I learned how to use the make_release script tools
15:52:15 <bshum> And the first alpha tarball is up on the downloads page now.
15:52:26 <kmlussier> bshum++
15:52:47 <bshum> mceraso is actually testing the alpha tarball for me right now, but if anyone else has good or bad things to say about it, please let me know.
15:53:10 <bshum> #info 2.7.0 alpha1 was cut and available from downloads page on Evergreen website
15:53:34 <bshum> #info 2.7.0 beta1 cutoff date is August 7, 2014 (next Thursday)
15:53:55 <kmlussier> Any questions for bshum before we move on?
15:54:03 <bshum> Speaking on the beta deadline, if there's any specific things that people are working on that they really want in 2.7, this is the time to get action on LP for them.
15:54:34 <kmlussier> bshum: What kind of action?
15:54:57 <bshum> kmlussier: At a minimum, either targeting towards 2.next with pullrequest, etc.
15:55:01 <ldw> bshum: I have updated LP1084269
15:55:18 <kmlussier> Is there a deadline on when the pullrequest tag needs to be added to make the beta cutoff?
15:55:28 <ldw> I need to target it for 2.next, but I can do that before the 7th
15:55:30 <bshum> That's a good question.
15:55:39 <bshum> The beta cutoff is actually supposed to be review too
15:55:48 <bshum> Meaning we have to actually push those things to master for them to be included.
15:55:59 <bshum> So it's not just mark them for review (which should be done as soon as possible)
15:56:17 <bshum> But also a general call for getting review and edits done to work so that new features are included.
15:57:09 <bshum> I've been saying it in IRC and I think I mentioned it in the last email, but perhaps I should write a more dedicated, "HEY PUSH THINGS" email to developers so that we can get as much work done as possible.
15:57:12 <vlewis> tsbere Thanks
15:57:53 <Dyrcona> Well, that brings up something that I thought of earlier today: lp1347774.
15:58:10 <kmlussier> I have some code I plan to test over the next week, but I don't have the power to push, just sign off. I don't know if that helps expedite the process.
15:58:24 <bshum> Given our general reliance on a week's time to review new features before push, perhaps the cutoff for new LP pullrequest targets ought to be this Thursday, July 31
15:58:37 <kmlussier> https://bugs.launchpad.net/evergreen/+bug/1347774
15:58:38 <pinesol_green> Launchpad bug 1347774 in Evergreen "Backend logic has leaked into the TPAC (and friends)" (affected: 2, heat: 12) [Wishlist,New]
15:58:48 <bshum> That way we get one week to review and then push in by August 7 beta date.
15:59:08 <Dyrcona> kmlussier: Thanks, my pinesol-foo is weak. :)
15:59:13 <kmlussier> Does the July 31 date sound agreeable to everyone?
15:59:17 <bshum> I imagine we'll do more triage and fixing for anything that gets rattled in the time between beta and RC.
15:59:32 <berick> kmlussier: sign off's do help speed things up
15:59:43 <Dyrcona> Is the goal to get those changes into 2.7.0, and do we think that is possible?
16:00:40 <kmlussier> eeevil ^ ^
16:00:48 * eeevil reads up
16:00:55 <eeevil> sorry, got distracted
16:01:51 <Dyrcona> Basically, should using backend logic used in TPAC stop something new from going into 2.7?
16:02:06 <eeevil> yeah, if we can get that in, it would be really great. I have a first-cut of the anon-pcrud service I'll post
16:02:55 <eeevil> Dyrcona: do you have a new feature in mind that wants to do that?
16:03:39 <eeevil> (many probably do want to. this has been one of the blockers in the past -- "there's precedent!" -- but it's bad precedent :( )
16:03:53 <Dyrcona> eeevil: It's more of a radical bug fix that had a pull request since early June until this morning: lp 1208875
16:03:54 <pinesol_green> Launchpad bug 1208875 in Evergreen "OPAC: My Account: Download Checkout History CSV breaks when there are a large number of items in the history" (affected: 5, heat: 26) [Medium,Confirmed] https://launchpad.net/bugs/1208875
16:03:54 <eeevil> blockers to attacking this problem, I mean
16:04:34 <Dyrcona> Well, I like using CStoreEditor, for one thing. :)
16:04:36 <bshum> It was on my list of things to test and include for alpha but I missed my own deadline that week, fwiw.
16:04:37 <eeevil> Dyrcona: that's totally fair. if I can adjust that to fit, would that be a fair compromise?
16:04:56 <eeevil> Dyrcona: you'll get to keep using cstore editor
16:05:01 <eeevil> that's a big part of the plan
16:05:06 <Dyrcona> eeevil: Sure, but I'm willing to rework it if necessary.
16:05:07 <eeevil> (minus json_query)
16:05:42 <Dyrcona> OK. I'll keep an eye out for branches.
16:06:10 <kmlussier> #info any new features for 2.7 should have a pullrequest tag by July 31.
16:06:30 <kmlussier> #help We need volunteers to test and push code for 2.7
16:06:40 <jeff> eeevil: are you saying you'll adjust the code for bug 1208875 to work under the new reality of bug 1347774?
16:06:42 <pinesol_green> Launchpad bug 1208875 in Evergreen "OPAC: My Account: Download Checkout History CSV breaks when there are a large number of items in the history" (affected: 5, heat: 26) [Medium,Confirmed] https://launchpad.net/bugs/1208875
16:06:43 <pinesol_green> Launchpad bug 1347774 in Evergreen "Backend logic has leaked into the TPAC (and friends)" (affected: 2, heat: 12) [Wishlist,New] https://launchpad.net/bugs/1347774
16:07:07 <jeff> eeevil: or something else -- just trying to see if i understood
16:07:23 * Dyrcona is fine with doing the adjusting. He just needs something to work with. :)
16:07:53 <berick> Dyrcona: basically json_query, update, delete, create, and any retrieve/search calls on non-public data have to move into an API call somewhere
16:08:04 <eeevil> jeff: I think it's fair of Dyrcona to say that his code's been their waiting, and if I want to disrupt it, I should help fix it (I'm putting words in his mouth...)
16:08:15 <kmlussier> Do we have anything else for the 2.7 release?
16:08:51 <eeevil> Dyrcona: what berick said ... you shouldn't need new code, just move existing private-assuming code.
16:08:52 <jeff> eeevil: got it. thanks!
16:09:10 <kmlussier> It's already past the hour mark and we have 2 agenda items. Do we want to push on or move the discussion of the last two items to the list?
16:09:19 <kmlussier> One has already been started on the list.
16:09:20 <eeevil> kmlussier: I'll hush. sorrry
16:10:10 <kmlussier> Hearing no opinions, I'm just going to press on. :)
16:10:20 <kmlussier> topic: Bug Squashing Days
16:10:28 <kmlussier> #link http://markmail.org/message/i52gh26swaewnqzo
16:10:31 <jeff> +1 to bug squashing days
16:10:33 <kmlussier> Bah!
16:10:39 <kmlussier> #topic Bug Squashing Days
16:11:00 <kmlussier> I have nothing to add to the e-mail. I just want to know if the dev community is okay with me moving forward to schedule a Bug Squashing Day.
16:11:07 <csharp> +1
16:11:36 <eeevil> it's worth a try, and the earlier we know about it the more likely we can clear our plates for the day
16:11:57 <kmlussier> Also, would anyone be interested in volunteering to do one of the extras I listed in the e-mail (setting up a scoreboard and maybe even a Sandbox)?
16:12:19 <kmlussier> eeevil: I was thinking of shooting for the end of August to give us some time to plan.
16:12:30 <jeff> I'd be interested in hearing from those with more Koha community experience to know if there are challenges we should look out for, or areas where Evergreen lacks some infrastructure (like sandboxes?) that would present a unique challenge.
16:13:25 <kmlussier> gmcharlt: Do you have any insights to offer?
16:13:27 <gmcharlt> the lack of sandboxes is a problem
16:13:45 <yboston> kmlussier: I would like to help one way or another. One way I would like to help is put together a tutorial to gelp first time voluneteers, like creating tips for installing EG through Git
16:13:51 <gmcharlt> at least with respect to including as many people as possible who can test but who aren't necessarily in a position to apply particular fixes
16:14:04 <hopkinsju> MOBIUS could provide one or more sandboxes, gmcharlt
16:14:31 <gmcharlt> a possible mitigation would be to arrange for folks to claim bugs before the big day
16:14:37 <gmcharlt> and set up environments before hand
16:14:57 <jeff> Koha's sandboxes are quite automated from what I understand -- we might be able to replicate with a "please create a sandbox with the branch for this bug" and some manual work before the day-of?
16:15:11 <jeff> gmcharlt++ (jinx?)
16:15:14 <gmcharlt> hopkinsju: one thing to note: the sandboxes that Koha has, which are operated (mostly) by BibLibre, provide an interface for a user to specify a bug number, then a few minutes later get a running Koha instance with the patches for that bug applied
16:15:36 <kmlussier> It seems like the Koha sandboxes are fairly automated. I was trying to think through how patches could be added on an Evergreen sandbox, and it seemed like it would need to be a little more manual. (jeff beat me to it.)
16:15:41 <gmcharlt> jeff: yep, sounds like the two of use are on the same page
16:15:47 <gmcharlt> MIND MELD!
16:16:01 * Dyrcona has automated most of that for his nearly daily VM builds.
16:16:03 <hopkinsju> Thats awfully fancy.
16:16:12 <kmlussier> Also, would we need more than one sandbox.
16:16:22 <kmlussier> It seems like branches might conflict if everything happened on one?
16:16:29 <gmcharlt> yep, multiples would help
16:16:41 <jeff> kmlussier: one per bug/branch would be what i was thinking
16:16:51 <gmcharlt> so to expand my suggestion... I think lining up volunteers in advance would really help
16:16:59 <gmcharlt> both for hosting test envs, and for doing testing
16:17:23 <kmlussier> To speed things along, maybe we can move the Sandbox discussion to the dev list to see if we can make this happen.
16:18:29 <kmlussier> #action kmlussier to move Sandbox discussion to dev list
16:18:50 <jeff> +1
16:19:05 <kmlussier> hopkinsju++ #Volunteering a MOBIUS test server
16:19:20 * kmlussier will move forward with bug squashing plans.
16:19:42 <kmlussier> #topic Web client's circulation module preview for Evergreen and websockets for OpenSRF
16:19:52 <kmlussier> bshum: Was this your topic?
16:20:11 <bshum> kmlussier: Yes, but we covered a lot of it earlier with the websockets talk just now.
16:20:21 <jeff> of the three options presented in the agenda, i like the first option best, and i'm almost certain that it is actually what was agreed upon earlier with regard to opensrf alpha scheduling. :-)
16:20:32 <bshum> I think the only outstanding part of it is whether berick thinks we'll want to include the web client circ module preview for 2.7 beta
16:21:05 <berick> well, we certainly can.. technically.
16:21:17 <berick> whether we want to is a broader question
16:21:28 <berick> sprint 1 is on schedule to be done toward the end of this week.
16:21:42 <berick> It’s tracking Evergreen master, so I’m not expecting any merge conflicts
16:21:49 <berick> or other oddities
16:21:58 <jeff> if it were included without changes to the 2.7 beta timeline, do you think that it would be a useful representation of the web-based features?
16:22:15 <kmlussier> By adding it as a preview, will it make it easier for more people to test?
16:22:31 <berick> jeff: yes; kmlussier: i would think yes
16:22:58 <berick> Assuming web sockets is merged, there’s one other bit of testing we would need to merge the browser client.
16:23:19 <berick> There are a couple of places where existing (non-browser client) code had to be modified for integration (e.g. opac).  Affected areas will need to be tested in the XUL client to make sure nothing was broken.
16:23:35 <berick> I could create a list.  There aren’t very many of these.
16:24:12 <berick> otherwise, it should go unnoticed for anyone not looking for it
16:24:43 <jeff> process-wise, would a lp bug for the circ-bits with notes on pre-reqs (websockets in opensrf) and a list of things to pay attention to when testing (berick's "list" just now) be the way to get it targeted for 2.7 beta in time for thursday?
16:25:00 <kmlussier> The possibility of breakage in the existing client makes me a little nervous. On the other hand, I would love to make it available for wider testing.
16:26:22 <berick> it occurs to me the build/install process might need some more work, too
16:26:36 <berick> it's been a while since I've looked at that
16:27:01 <berick> if the requiremetn for 2.7 is basically "don't break anything", then I think this is very doable
16:27:16 <bshum> berick: I can work with that.
16:27:38 <kmlussier> "don't break anything" is a good goal to have. :)
16:27:38 <bshum> I'd like to get it included as a preview as long as it doesn't interfere too much.  Though I am curious to see the list of affected areas now :)
16:28:02 <kmlussier> berick: Can I add an action item for you to add a LP bug as jeff described above?
16:28:07 <berick> bshum: it's pretty small. shall I start w/ that in a LP like jeff ...
16:28:08 <berick> heh
16:28:12 <berick> kmlussier: yes you may ;)
16:28:16 <bshum> berick: Sure
16:28:57 <bshum> Hey, look at it this way, we can always roll back :P
16:28:59 <kmlussier> #action berick to add an LP bug for web based circ client with notes on pre-reqs and a list of existing client interfaces that need special attention.
16:29:24 <kmlussier> Anything else before we wrap up?
16:30:00 <kmlussier> Going once, going twice...
16:30:11 <kmlussier> #endmeeting