14:05:07 <bshum> #startmeeting Evergreen Developer Meeting - 2014-06-12
14:05:07 <pinesol_green> Meeting started Thu Jun 12 14:05:07 2014 US/Eastern.  The chair is bshum. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:05:07 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:05:07 <pinesol_green> The meeting name has been set to 'evergreen_developer_meeting___2014_06_12'
14:05:14 <bshum> #topic Introductions
14:05:20 <bshum> #info bshum = Ben Shum, Bibliomation
14:05:22 <DPearl1> #info DPearl1 is Dan Pearl from C/W MARS Inc.
14:05:26 <bshum> Let's see who we've got and we'll see what we cover
14:05:33 <kmlussier> #info kmlussier = Kathy Lussier, MassLNC
14:05:34 <RoganH> #info RoganH = Rogan Hamby, SCLENDS
14:05:57 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College)
14:06:00 <remingtron> #info remingtron is Remington Steed, Hekman Library (Calvin College)
14:06:00 <bshum> #link Agenda:  http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-06-12
14:06:03 <bshum> I'll add more to it as we go
14:06:06 <dkyle> #info dkyle Doug Kyle, Grand Rapids Public Library
14:08:32 <bshum> Okie dokie
14:08:49 <bshum> So as others fill in, feel free to announce yourselves.  But we'll move forward.
14:09:00 <bshum> #topic Past action items from last meeting
14:09:11 <bshum> #info eeevil After 2.6.0 is cut, eeevil to publish detailed plan about freezing baseline schemas between EG releases and using deprecates/supersedes in database upgrade scripts. This will go on the mailing list and the thread should structure further discussion of pros and cons of eeevil's plan.
14:09:35 <eeevil> #info eeevil = Mike Rylander, ESI
14:09:45 <bshum> I assume that's still ongoing, but as a related note on that plan, I think I'd like to take this moment to discuss dbwells' notes on the dev list about upgrade paths.
14:09:54 <eeevil> bshum: not yet.  I plan to jump on dbwells' thread
14:09:59 <eeevil> heh
14:10:48 <bshum> #link dbwells' plan:  http://markmail.org/message/tl5d3tnupq2istx7
14:11:05 <bshum> I just linked to the thread dbwells started on the dev list to talk about new approaches for upgrade strategy.
14:11:10 <gmcharlt> #info gmcharlt = Galen Charlton, ESI
14:11:24 <bshum> I'm tardy with my own reply, but I'm curious to see what we can hammer out as we move forward this summer.
14:11:59 <bshum> #help Get more responses and ideas sent to list about future Evergreen upgrade strategy.
14:12:04 <dbwells> Anything I do with regards to that thread will be short-term, hopefully.
14:13:03 <bshum> Sounds reasonable.
14:13:10 <bshum> dbwells++ for getting the ball rolling
14:13:38 <bshum> Okay
14:13:40 <bshum> #topic OpenSRF release
14:13:59 <bshum> gmcharlt: Springing this on you, but do you have any thoughts about 2.4 work?
14:14:34 <gmcharlt> bshum: aiming for a release after ALA
14:14:57 <bshum> #info gmcharlt aiming for an OpenSRF 2.4 release after ALA
14:15:07 <gmcharlt> main thing I'd like at this point is more testing of the websocket work by berick
14:15:48 <bshum> #info Get more testing of the websocket work started by berick, see https://bugs.launchpad.net/opensrf/+bug/1268619 and others
14:15:48 <pinesol_green> Launchpad bug 1268619 in OpenSRF "WebSockets Gateway and JS Library" (affected: 1, heat: 6) [Undecided,New]
14:16:27 <bshum> Sounds like a good thing.
14:17:53 <bshum> Okay, we'll follow up on that after ALA, but in the meantime, folks should check out the bug and other announcements to help start testing the upcoming work for OpenSRF.
14:18:02 <bshum> Thanks for the update gmcharlt++
14:18:17 <bshum> #topic Evergreen maintenance releases
14:19:14 <dbwells> #info 2.5.5 and 2.6.1 are out
14:19:47 <bshum> The next date on the calendar for that is 6/18, do we want to stick to that or perhaps shift things slightly?
14:20:04 <bshum> dbwells++ # doing the release dance
14:21:30 <dbwells> I haven't managed to hit the dates yet, but I think pushing it back will just give me a new date to not hit.
14:21:35 <bshum> I'm not sure how much review we're able to get done over the next week, but I feel like there's a lot of things on the pullrequest tagged towards 2.6.2
14:22:06 <bshum> Oh, fewer than I thought actually
14:22:14 <bshum> https://bugs.launchpad.net/evergreen/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.
14:22:14 <bshum> milestone%3Alist=66077&field.tag=pullrequest+&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on
14:22:16 <bshum> Gah, sorry
14:22:20 <bshum> Just 7
14:22:31 * bshum will try shortening his URLs next time)
14:23:13 <dbwells> I think it is best for maintenance releases to come out as on-time as possible, and whatever is in, is in.  A month really isn't that long.
14:23:19 <bshum> Okay, so if dbwells, you'd prefer to stick with the current timeline, let's make our best effort to meet that then.
14:23:25 <dbwells> sounds good
14:23:56 <dbwells> I'll get it right, this time!
14:24:01 <bshum> #info Next maintenance releases due out on 6/18/14.  Core committers and other reviewers, please make best effort to look at bugs and sign-off on work.
14:24:56 <bshum> Okay
14:25:07 <bshum> #topic Evergreen 2.7 update
14:25:23 <dbwells> To be clear, I consider 6/18 to be the date when I branch and make the preview build.
14:25:45 <bshum> #info Today (6/12) was the new date to assign first milestones for major work to be considered for 2.7.
14:26:47 <bshum> I see that we have lots of stuff lined up nicely for 2.next.
14:27:14 <berick> i still need to add an LP for a minor-ish thing.  will do so shortly.
14:27:47 <bshum> berick: I told myself that I can expect an LP for first web client work whenever you're ready.  I think everybody generally expects that to happen when it happens.
14:28:00 <bshum> Hopefully not a surprise ;)
14:28:36 <berick> heh, no, not a surprise.  i could use some feedback on how best to structure it though.. one LP first sprint 1 or broken out, etc.
14:29:44 <berick> but, yeah, still a good bit of work to do before anything is done-ish
14:30:58 <bshum> Hmm, I think one bug per sprint sounds like it might not be unreasonable as a starting point.  We may find that individual bugs may be necessary to track specific issues though?
14:31:29 <bshum> I guess it depends on how comfortable you are separating the parts of the sprint into separate bugs
14:31:41 <bshum> We could track the whole sprint as a blueprint and link it to each bug separately.
14:31:59 <bshum> I guess it's more about how the final code will be presented.
14:32:30 <berick> well, for the initial round of testing, i'm considering maintaining maybe a simple list somewhere.  there will be /lots/ of little things.  opening LP's for each would be cumbersome, imo.
14:32:40 <dbs> #info dbs, Laurentian University
14:32:48 <berick> after that's settled down, though, then we can leverage LP in the usual fashion
14:33:00 <bshum> Sounds reasonable to me.
14:34:03 <bshum> Any other thoughts for berick at this time?
14:34:16 <bshum> berick: Or any specific areas you would like to mention about the web client work?
14:34:32 <bshum> berick++ by the way, for sending out regular updates on the ongoing efforts
14:34:38 <bshum> (and getting feedback)
14:34:46 <dbs> berick++
14:34:50 <RoganH> berick++
14:34:56 <berick> lately i'm in the trenches, so no super interesting udpates to provide
14:34:56 <kmlussier> berick++
14:34:57 <dbwells> berick++
14:34:58 <berick> just working thorugh UIs
14:35:03 <berick> aw, shucks
14:35:05 <jeff> berick++
14:35:13 <jeff> and greetings.
14:35:35 <berick> i am curious if we want to try to roll any of this out with the next release
14:35:39 <berick> as a preview type thing
14:35:45 <dbs> tpac-style
14:35:54 <bshum> Next release meaning 2.7?
14:35:54 <RoganH> I'm in favor of that.
14:36:13 <berick> it will mean we really need to get in the websockets testing
14:36:20 <dbwells> +1 to including as a preview
14:36:25 <bshum> +1 to preview
14:36:43 <berick> bshum: right, next meaning 2.7
14:36:46 <berick> it's pushing it close
14:37:03 <bshum> Well, let's see how you feel before beta cutoff then
14:37:13 <berick> remind me of the date, plz?
14:37:19 <bshum> Which is August 7
14:37:23 <berick> thanks
14:37:24 <bshum> (had to look it up myself)
14:38:29 <berick> fortunately, the code is almost entirely standalone and outside the realm of everday EG code
14:38:34 <bshum> Okay, sounds like a reasonable goal to try for ;)
14:38:42 <berick> there's a few IDL changes and, IIRC, 1 minor API change
14:38:50 <berick> so, the big thing really is just the websockets stuff
14:39:04 <berick> as far as disrupting the status quo goes
14:39:17 <dbwells> berick: Granting you 4 hours of sleep per night, you still have 1000+ hours before the beta cutoff, plenty of time
14:39:27 <jeff> dbwells++
14:39:43 <bshum> Heh
14:39:52 <hbrennan> bshum: Your guidance, nor my actions yesterday, were the cause of the checkout breaking!
14:40:04 <hbrennan> *not your guidance
14:40:14 <hbrennan> Whatever, stupid english grammar
14:40:17 * berick takes 100 10-minute naps 60 times
14:41:05 <bshum> Okay, anything else for this topic before we move on?  (next up, brief mentions about ongoing activities)
14:41:57 <bshum> Okay
14:42:05 <bshum> #topic The Hack-A-Way potential location
14:42:20 <RoganH> The 2014 Hack-A-Way poll is open until next Friday the 20th at midnight EST.
14:42:31 <RoganH> #info hackaway poll http://doodle.com/qzzfem72ixntitnv
14:42:47 <RoganH> Right now Rock Hill, SC being sponsored by the York Public Library is in the lead
14:43:05 <RoganH> After a location is chosen I will poll attendees to determine the dates.
14:43:13 <RoganH> Any questions at this point?
14:43:29 <kmlussier> RoganH++
14:43:43 <bshum> RoganH++
14:43:51 <berick> RoganH++
14:44:22 <RoganH> If it's Rock Hill the hotel will probably be the Holiday Inn (its just been remodeled and is very nice) right off I-77.  Cheap, easy to get to.
14:44:39 <bshum> Going beyond the location, I think that it's worth noting that last year's hack-a-way we did have some offsite participants using Google hangout.  But we hope to see as many show up in-person as possible to hack together ;)
14:44:40 <RoganH> It's about 20 minutes from the Charlotte Airport.  And York will probably cater lunch 2 or 3 days.
14:45:13 <RoganH> Agreed.  And I'm going to look at how we can do more with Google hangout but I don't doubt that being there in person has distinct advantages.
14:45:29 <RoganH> Still, I want to be as inclusive as possible with the Hangouts because just not everyone can make the trek.
14:46:02 <bshum> We'll see what happens as details unfold.  In the meantime, fill out the poll and spread the word!
14:46:05 <dbs> as a hangout participant last time, I thank you :)
14:46:26 <RoganH> That was my first real playing with Hangouts.  I've come to love them and think we can do a better job with them this year.
14:46:40 <RoganH> I use them a lot now.
14:47:12 <bshum> Any other questions for RoganH before we move on (next up, notable mentions, aka some short announcements time)
14:47:13 <berick> hackaway will just be us building raspberry pi cameras ;)
14:48:10 <RoganH> berick: pre-hackfest event :)
14:48:17 <bshum> #topic Other Mentions
14:48:17 <berick> it's on!
14:48:36 <bshum> #info dbs brought up phabricator as a potential replacement for LP, etc.
14:49:01 <bshum> #link Wikimedia blog post about their move:  http://blog.wikimedia.org/2014/06/10/on-our-way-to-phabricator/
14:49:33 <dbs> fwiw, I consider that a very low priority item, just putting a pin in it for the next time the "GAWD I HATE LAUNCHPAD" discussion swells up
14:49:37 <bshum> While I don't have the tuits right now, this has sparked some interest for me, and I wanted it on the notes.
14:50:00 <dbwells> I haven't delved deeply, but I think Phabricator looks pretty nice.
14:50:31 <dbwells> Other than being PHP, but I can get over it.
14:51:30 <bshum> Heh, yeah, well, LP hate comes up every once in awhile ;)
14:51:39 <bshum> dbs++ for keeping his eyes open
14:52:05 <dkyle> #link change floating back to bool: https://bugs.launchpad.net/evergreen/+bug/1319919. wonder if there is agreement on this?
14:52:05 <pinesol_green> Launchpad bug 1319919 in Evergreen "upgrading to 2.5+ can break copy templates" (affected: 6, heat: 32) [Undecided,New]
14:52:05 <RoganH> Any idea how cumbersome migrating from LP to Phabricator would be?  Some casual googling brings up a lot of bugzilla to Phabricator links but not much for LP.
14:53:00 <bshum> RoganH: That was my first question too, I haven't dug up enough yet.  Maybe we do the LP->bugzilla->Phabricator dance then?  (he says half joking)
14:53:31 <RoganH> That's not a -1, just throwing out the question.  Some quick searches don't make an informed opinion on my part :)
14:53:36 <bshum> Certainly worth someone looking more closely at when we get more time.
14:54:26 <bshum> Anywho, that's all I had for this segment.  The last thing on the actual agenda was talking about new development, but we can take a moment to talk about what dkyle just brought up too.
14:55:20 <bshum> Well, actually, let's stick with the time, given what we have left.
14:55:41 <bshum> #topic Feedback for New Features under development
14:56:15 <bshum> #info Conditional Negative Balances - https://bugs.launchpad.net/evergreen/+bug/1198465
14:56:15 <pinesol_green> Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 12, heat: 52) [Wishlist,Confirmed]
14:56:36 <kmlussier> I don't have much to say on this topic because I know dbwells is planning to take a look at it this week. But I just want to say that it would be great if we could get eyes on this issue so that we can set a path forward.
14:56:47 <kmlussier> There are 11 people who have clicked the "me too" link in LP, which is a lot for this community. So it seems like this code is important to a lot of people, and I would hate to note see a solution by the time 2.7 is released.
14:57:03 <kmlussier> I'm going to reiterate (again) that I still prefer the original approach and would love to work with Dyrcona to dust off that branch and fix bugs that were found.
14:57:14 <kmlussier> But MassLNC is committed to working with the community to get this code working in some fashion. I just want to make sure it's done in a way that doesn't add confusion for the end user or for the sys admins who are troubleshooting problems.
14:57:30 <kmlussier> That's all I have to say at the moment. Well under the 2 minutes that bshum just gave me. :)
14:58:20 * dbs hopes to get back to Dyrcona's RDA bug real soon now too
14:59:23 <dbs> Ah, LP 1304462 but it looks like bshum is on that
14:59:23 <pinesol_green> Launchpad bug 1304462 in Evergreen "Add 264 tag values to Record Summary" (affected: 3, heat: 18) [Wishlist,In progress] https://launchpad.net/bugs/1304462 - Assigned to Ben Shum (bshum)
14:59:48 <bshum> For the record, when this work slipped away during 2.6 due to differing opinions by reviewers, I really hoped to make this a priority for 2.7.  So, speaking for myself as RM, I'd welcome any input on that bug to help forge our path forward.
14:59:49 <RoganH> kmlussier: A thought. At this point the LP entry for conditional negative balances is an impressive wall of text.  And I'm guilty of not going through it carefully since the first few posts.
15:00:07 <RoganH> kmlussier: Can this be simplified for discussion or does it have enough important nuance that it needs to be dug through?
15:00:32 <kmlussier> RoganH: I can certainly simplify it, but I have to admit I'm a bit biased on the whole discussion.
15:01:02 <kmlussier> My concern is that this bug ultimately has big impacts on end users, and they aren't really seeing the nuances of the different approaches.
15:01:50 <RoganH> kmlussier: I'm willing to read through it all.  I agree it's important.  I'm willing to do so and post about it but with the caveat that I might need correction if I miss a nuance.
15:02:04 <RoganH> (Actually that seems likely that I will.)
15:02:41 <kmlussier> For end users (not the devs), it might also be useful to have side-by-side screenshots of what happens. But, although I have done numerous screenshots in my last round of testing, I don't have much for what the original approach did.
15:03:21 <jeffdavis> A summary post about it to open-ils-general or open-ils-dev would be useful, I think - dunno if our support folks have looked at the bug so far.
15:03:58 <bshum> Oh boy, netsplits.
15:04:14 <kmlussier> I'm happy to work on a summary post and even post it here as a check against potential bias.
15:04:32 <kmlussier> But it will have to wait until next week. Vacation day tomorrow.
15:04:57 <bshum> kmlussier: That sounds reasonable.  Plus it'll give dbwells some time to work on his reply he mentions in the last comment.
15:05:41 <bshum> I'm going to add action items for both of you on this and we'll follow up next meeting ;)
15:06:09 <bshum> #action dbwells to review and comment on conditional negative balance bug: https://bugs.launchpad.net/evergreen/+bug/1198465
15:06:09 <pinesol_green> Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 13, heat: 56) [Wishlist,Confirmed]
15:06:29 <bshum> #action kmlussier to work on summary of bug to list and gather more feedback to move forward
15:06:46 <dbwells> I've said a lot in the thread, and don't want to speak too much for eeevil, but we're taking the approach of preserving/extending the existing functionality rather than replacing.  I know some of the complaints are UI related, but I think that can all be secondary to ironing things out on the conceptual level.
15:08:31 <bshum> Okay, we're over our time (though we did start late).
15:08:51 <eeevil> dbwells: in short, I agree. however, I'm not going to have the tuits in the short term (you mentioned this or next week) to get heavily involved
15:09:00 <bshum> Thanks for sticking with me on this loosely formed agenda.  We'll aim to do better next time.
15:09:15 <eeevil> bshum++
15:09:24 <DPearl1> bshum++   You did just fine
15:09:35 <bshum> I'm going to close this meeting, but suggest continuing any conversations for those who stick around.
15:09:39 <jeff> bshum++ way better than that guy who ran the last few meetings ;-)
15:09:40 <kmlussier> bshum++ #Making up your own agenda. :)
15:09:42 <bshum> #endmeeting