14:05:07 #startmeeting Evergreen Developer Meeting - 2014-06-12 14:05:07 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:05:07 The meeting name has been set to 'evergreen_developer_meeting___2014_06_12' 14:05:14 #topic Introductions 14:05:20 #info bshum = Ben Shum, Bibliomation 14:05:22 #info DPearl1 is Dan Pearl from C/W MARS Inc. 14:05:26 Let's see who we've got and we'll see what we cover 14:05:33 #info kmlussier = Kathy Lussier, MassLNC 14:05:34 #info RoganH = Rogan Hamby, SCLENDS 14:05:57 #info dbwells = Dan Wells, Hekman Library (Calvin College) 14:06:00 #info remingtron is Remington Steed, Hekman Library (Calvin College) 14:06:00 #link Agenda: http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-06-12 14:06:03 I'll add more to it as we go 14:06:06 #info dkyle Doug Kyle, Grand Rapids Public Library 14:08:32 Okie dokie 14:08:49 So as others fill in, feel free to announce yourselves. But we'll move forward. 14:09:00 #topic Past action items from last meeting 14:09:11 #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 #info eeevil = Mike Rylander, ESI 14:09:45 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 bshum: not yet. I plan to jump on dbwells' thread 14:09:59 heh 14:10:48 #link dbwells' plan: http://markmail.org/message/tl5d3tnupq2istx7 14:11:05 I just linked to the thread dbwells started on the dev list to talk about new approaches for upgrade strategy. 14:11:10 #info gmcharlt = Galen Charlton, ESI 14:11:24 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 #help Get more responses and ideas sent to list about future Evergreen upgrade strategy. 14:12:04 Anything I do with regards to that thread will be short-term, hopefully. 14:13:03 Sounds reasonable. 14:13:10 dbwells++ for getting the ball rolling 14:13:38 Okay 14:13:40 #topic OpenSRF release 14:13:59 gmcharlt: Springing this on you, but do you have any thoughts about 2.4 work? 14:14:34 bshum: aiming for a release after ALA 14:14:57 #info gmcharlt aiming for an OpenSRF 2.4 release after ALA 14:15:07 main thing I'd like at this point is more testing of the websocket work by berick 14:15:48 #info Get more testing of the websocket work started by berick, see https://bugs.launchpad.net/opensrf/+bug/1268619 and others 14:15:48 Launchpad bug 1268619 in OpenSRF "WebSockets Gateway and JS Library" (affected: 1, heat: 6) [Undecided,New] 14:16:27 Sounds like a good thing. 14:17:53 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 Thanks for the update gmcharlt++ 14:18:17 #topic Evergreen maintenance releases 14:19:14 #info 2.5.5 and 2.6.1 are out 14:19:47 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 dbwells++ # doing the release dance 14:21:30 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 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 Oh, fewer than I thought actually 14:22:14 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 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 Gah, sorry 14:22:20 Just 7 14:22:31 * bshum will try shortening his URLs next time) 14:23:13 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 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 sounds good 14:23:56 I'll get it right, this time! 14:24:01 #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 Okay 14:25:07 #topic Evergreen 2.7 update 14:25:23 To be clear, I consider 6/18 to be the date when I branch and make the preview build. 14:25:45 #info Today (6/12) was the new date to assign first milestones for major work to be considered for 2.7. 14:26:47 I see that we have lots of stuff lined up nicely for 2.next. 14:27:14 i still need to add an LP for a minor-ish thing. will do so shortly. 14:27:47 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 Hopefully not a surprise ;) 14:28:36 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 but, yeah, still a good bit of work to do before anything is done-ish 14:30:58 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 I guess it depends on how comfortable you are separating the parts of the sprint into separate bugs 14:31:41 We could track the whole sprint as a blueprint and link it to each bug separately. 14:31:59 I guess it's more about how the final code will be presented. 14:32:30 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 #info dbs, Laurentian University 14:32:48 after that's settled down, though, then we can leverage LP in the usual fashion 14:33:00 Sounds reasonable to me. 14:34:03 Any other thoughts for berick at this time? 14:34:16 berick: Or any specific areas you would like to mention about the web client work? 14:34:32 berick++ by the way, for sending out regular updates on the ongoing efforts 14:34:38 (and getting feedback) 14:34:46 berick++ 14:34:50 berick++ 14:34:56 lately i'm in the trenches, so no super interesting udpates to provide 14:34:56 berick++ 14:34:57 berick++ 14:34:58 just working thorugh UIs 14:35:03 aw, shucks 14:35:05 berick++ 14:35:13 and greetings. 14:35:35 i am curious if we want to try to roll any of this out with the next release 14:35:39 as a preview type thing 14:35:45 tpac-style 14:35:54 Next release meaning 2.7? 14:35:54 I'm in favor of that. 14:36:13 it will mean we really need to get in the websockets testing 14:36:20 +1 to including as a preview 14:36:25 +1 to preview 14:36:43 bshum: right, next meaning 2.7 14:36:46 it's pushing it close 14:37:03 Well, let's see how you feel before beta cutoff then 14:37:13 remind me of the date, plz? 14:37:19 Which is August 7 14:37:23 thanks 14:37:24 (had to look it up myself) 14:38:29 fortunately, the code is almost entirely standalone and outside the realm of everday EG code 14:38:34 Okay, sounds like a reasonable goal to try for ;) 14:38:42 there's a few IDL changes and, IIRC, 1 minor API change 14:38:50 so, the big thing really is just the websockets stuff 14:39:04 as far as disrupting the status quo goes 14:39:17 berick: Granting you 4 hours of sleep per night, you still have 1000+ hours before the beta cutoff, plenty of time 14:39:27 dbwells++ 14:39:43 Heh 14:39:52 bshum: Your guidance, nor my actions yesterday, were the cause of the checkout breaking! 14:40:04 *not your guidance 14:40:14 Whatever, stupid english grammar 14:40:17 * berick takes 100 10-minute naps 60 times 14:41:05 Okay, anything else for this topic before we move on? (next up, brief mentions about ongoing activities) 14:41:57 Okay 14:42:05 #topic The Hack-A-Way potential location 14:42:20 The 2014 Hack-A-Way poll is open until next Friday the 20th at midnight EST. 14:42:31 #info hackaway poll http://doodle.com/qzzfem72ixntitnv 14:42:47 Right now Rock Hill, SC being sponsored by the York Public Library is in the lead 14:43:05 After a location is chosen I will poll attendees to determine the dates. 14:43:13 Any questions at this point? 14:43:29 RoganH++ 14:43:43 RoganH++ 14:43:51 RoganH++ 14:44:22 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 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 It's about 20 minutes from the Charlotte Airport. And York will probably cater lunch 2 or 3 days. 14:45:13 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 Still, I want to be as inclusive as possible with the Hangouts because just not everyone can make the trek. 14:46:02 We'll see what happens as details unfold. In the meantime, fill out the poll and spread the word! 14:46:05 as a hangout participant last time, I thank you :) 14:46:26 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 I use them a lot now. 14:47:12 Any other questions for RoganH before we move on (next up, notable mentions, aka some short announcements time) 14:47:13 hackaway will just be us building raspberry pi cameras ;) 14:48:10 berick: pre-hackfest event :) 14:48:17 #topic Other Mentions 14:48:17 it's on! 14:48:36 #info dbs brought up phabricator as a potential replacement for LP, etc. 14:49:01 #link Wikimedia blog post about their move: http://blog.wikimedia.org/2014/06/10/on-our-way-to-phabricator/ 14:49:33 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 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 I haven't delved deeply, but I think Phabricator looks pretty nice. 14:50:31 Other than being PHP, but I can get over it. 14:51:30 Heh, yeah, well, LP hate comes up every once in awhile ;) 14:51:39 dbs++ for keeping his eyes open 14:52:05 #link change floating back to bool: https://bugs.launchpad.net/evergreen/+bug/1319919. wonder if there is agreement on this? 14:52:05 Launchpad bug 1319919 in Evergreen "upgrading to 2.5+ can break copy templates" (affected: 6, heat: 32) [Undecided,New] 14:52:05 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 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 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 Certainly worth someone looking more closely at when we get more time. 14:54:26 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 Well, actually, let's stick with the time, given what we have left. 14:55:41 #topic Feedback for New Features under development 14:56:15 #info Conditional Negative Balances - https://bugs.launchpad.net/evergreen/+bug/1198465 14:56:15 Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 12, heat: 52) [Wishlist,Confirmed] 14:56:36 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 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 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 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 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 Ah, LP 1304462 but it looks like bshum is on that 14:59:23 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 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 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 kmlussier: Can this be simplified for discussion or does it have enough important nuance that it needs to be dug through? 15:00:32 RoganH: I can certainly simplify it, but I have to admit I'm a bit biased on the whole discussion. 15:01:02 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 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 (Actually that seems likely that I will.) 15:02:41 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 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 Oh boy, netsplits. 15:04:14 I'm happy to work on a summary post and even post it here as a check against potential bias. 15:04:32 But it will have to wait until next week. Vacation day tomorrow. 15:04:57 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 I'm going to add action items for both of you on this and we'll follow up next meeting ;) 15:06:09 #action dbwells to review and comment on conditional negative balance bug: https://bugs.launchpad.net/evergreen/+bug/1198465 15:06:09 Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 13, heat: 56) [Wishlist,Confirmed] 15:06:29 #action kmlussier to work on summary of bug to list and gather more feedback to move forward 15:06:46 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 Okay, we're over our time (though we did start late). 15:08:51 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 Thanks for sticking with me on this loosely formed agenda. We'll aim to do better next time. 15:09:15 bshum++ 15:09:24 bshum++ You did just fine 15:09:35 I'm going to close this meeting, but suggest continuing any conversations for those who stick around. 15:09:39 bshum++ way better than that guy who ran the last few meetings ;-) 15:09:40 bshum++ #Making up your own agenda. :) 15:09:42 #endmeeting