[OPEN-ILS-DEV] Developer meeting this afternoon
Hi all, We have a developer meeting scheduled for this afternoon at 3 p.m. Eastern, 12 p.m. Pacific. Please join us in the #evergreen on the freenode channel to participate in the meeting. The draft agenda is available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2018-10-10. Feel free to add discussion items to the agenda. Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128kluss...@masslnc.org
Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] 3.2 Getting back on schedule
I can commit to testing patches for any of those bugs. Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128kluss...@masslnc.org On Tue, Sep 18, 2018 at 3:13 PM Galen Charlton wrote: > Hi, > > On Mon, Sep 17, 2018 at 4:50 PM Bill Erickson wrote: > > A few web staff blockers remain. Most of them have been there for > months, though, so I don't think another few days here or there is going to > make much difference. > > > > If that's an unfair assessment, let me know. > > Of the remaining open webstaffblocker bugs, I can commit to having > patches by Friday for the following ones: > > * https://bugs.launchpad.net/evergreen/+bug/1745427 (predict new > issues defaults to previous pattern) > > * https://bugs.launchpad.net/evergreen/+bug/1791340 (Web Client Hourly > Loan Checkin Time Wrong) > * https://bugs.launchpad.net/evergreen/+bug/1789442 (Web client: When > editing an hourly due date the time is automatically changed to 12:00 > am) > * https://bugs.launchpad.net/evergreen/+bug/1552778 (Web client > check-in "effective date" and check-out "specific due date" should > also include times) > > Note that for the two above that the fix I'm thinking of would either > require an OpenSRF update, as the main change is a fix to > cleanse_ISO8601, or (my preferred approach) copying cleanse_ISO8601 > over to Evergreen as (say) clean_ISO8601 and updating references > everywhere -- straightforward, but obviously would require a fair > amount of testing across the board. > > I think that amelioration, if not total fixes, should be straightforward > for: > > * https://bugs.launchpad.net/evergreen/+bug/1773191 (Untranslatable > Last Billing Type values) > * https://bugs.launchpad.net/evergreen/+bug/1791335 (Transferring > items and vol/items does not maintain stat cats) > > One that has a good start by Cesar, but looks like needs more discussion > is: > > * https://bugs.launchpad.net/evergreen/+bug/1746536 (web client: > cannot edit vol/call number in item status) > > If folks can commit to helping out with the last three in particular > and with testing patches for the first four, I think there would be > benefit to delaying the RC to the 24th to make it a true release > candidate. That said, this is a position I hold at +0.75, as it would > be reasonable for us to also choose to make 3.2.1 a hard target for > those bugs. > > Regards, > > Galen > -- > Galen Charlton > Implementation and Services Manager > Equinox Open Library Initiative > phone: 1-877-OPEN-ILS (673-6457) > email: g...@equinoxinitiative.org > web: https://equinoxInitiative.org > direct: +1 770-709-5581 > cell: +1 404-984-4366 >
Re: [OPEN-ILS-DEV] Informal vote to apply XUL-removal patch to 3.2
Hi Ben, Are you referring to the bug where copies cannot be edited after a part has been assigned? If so, that bug has been fixed. https://bugs.launchpad.net/evergreen/+bug/1739271 Kathy On Wed, Aug 29, 2018, 12:53 PM Benjamin Kalish wrote: > Hopefully this is missing from the webstaffblocker list because it's > already been fixed, but I couldn't confirm that on launchpad. We've had an > ongoing problem where item status changes made from "Edit Item Attributes" > in the web client are not saved, and the only workaround we've found at my > library has been to use the XUL client. We've submitted this bug to our > consortium (CW MARS) but I don't know for sure whether or not it was ever > submitted on LaunchPad. It is a big deal though! If it hasn't been fixed > than I honestly don't know what we would do without access to the XUL > client. > > Benjamin Kalish > Forbes Library / 413-587-1012 / bkal...@forbeslibrary.org > > Support Forbes Library: > >- Consider giving a gift <http://www.forbeslibrary.org/giving> to >Forbes Library >- Vote for the Friends of Forbes in the Florence Bank Community Grant >Program <https://www.florencebank.com/vote>. >- Join the Friends the Forbes today ><https://forbeslibrary.org/friends/>! > > > Currently reading: *Guastavino Vaulting: The Art of Structural Tile* by > John Ochsendorf > Just Finished: *There's a Mystery There: The Primal Vision of Maurice > Sendak* by Jonathan Cott > > For information about accessibility at the library, please see: > http://forbeslibrary.org/accessibility/ > > > > > > > > > > > > On Wed, Aug 29, 2018 at 12:40 PM Kathy Lussier > wrote: > >> Thank you for that assessment Galen. I'll note that the bugs that gave me >> the biggest concern were in the small category. The type to selection bug >> is indeed a big issue, particularly for large consortia who have to >> navigate through a large list of libraries. But my largest concern are with >> those bugs that don't have a good workaround aside from performing the >> action in the xul client. >> >> Kathy >> >> -- >> Kathy Lussier >> Project Coordinator >> Massachusetts Library Network Cooperative >> (508) 343-0128kluss...@masslnc.org >> >> >> >> On Wed, Aug 29, 2018 at 12:23 PM Galen Charlton < >> g...@equinoxinitiative.org> wrote: >> >>> Hi, >>> >>> Here's my classification of the current open bugs tagged as >>> webstaffblocker: >>> >>> Small (i.e., likely can be fixed in two weeks) >>> --- >>> https://bugs.launchpad.net/evergreen/+bug/1773191 Untranslatable Last >>> Billing Type values >>> https://bugs.launchpad.net/evergreen/+bug/1770959 Web staff client: >>> strings translated via staff client are displayed untranslated >>> https://bugs.launchpad.net/evergreen/+bug/1781641 Web Client: Cannot >>> Override Patron Message Block >>> https://bugs.launchpad.net/evergreen/+bug/1781235 Web Client: >>> Sometimes Unable to Change Primary Patron Barcode within "See All" Box >>> https://bugs.launchpad.net/evergreen/+bug/1746536 web client: cannot >>> edit vol/call number in item status >>> https://bugs.launchpad.net/evergreen/+bug/1745427 Web Client: Serials >>> - Predict New Issues Defaults to Previous Pattern >>> https://bugs.launchpad.net/evergreen/+bug/1552778 Web client check-in >>> "effective date" and check-out "specific due date" should also include >>> times >>> >>> Higher-effort >>> - >>> https://bugs.launchpad.net/evergreen/+bug/1511742 webclient: Need >>> ability to type to selection in some menus >>> >>> Patch exists, may need some tweaks >>> -- >>> https://bugs.launchpad.net/evergreen/+bug/1755258 webclient: LDAP not >>> working -- but works for stand alone client >>> >>> Overall, I think we can reasonably hope to resolve these over the next >>> couple weeks, although I specifically want to call out LP#1511742 as >>> the one bug that I think will require the most effort. >>> >>> Consequently, I am +1 for planning on disabling the XUL client in 3.2, >>> especially in light of plans for extending the support period for 3.1, >>> but do think that this decision needs to be evaluated and finalized at >>> the end of the upcoming bug-squashing week. >>> &
Re: [OPEN-ILS-DEV] Informal vote to apply XUL-removal patch to 3.2
Thank you for that assessment Galen. I'll note that the bugs that gave me the biggest concern were in the small category. The type to selection bug is indeed a big issue, particularly for large consortia who have to navigate through a large list of libraries. But my largest concern are with those bugs that don't have a good workaround aside from performing the action in the xul client. Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128kluss...@masslnc.org On Wed, Aug 29, 2018 at 12:23 PM Galen Charlton wrote: > Hi, > > Here's my classification of the current open bugs tagged as > webstaffblocker: > > Small (i.e., likely can be fixed in two weeks) > --- > https://bugs.launchpad.net/evergreen/+bug/1773191 Untranslatable Last > Billing Type values > https://bugs.launchpad.net/evergreen/+bug/1770959 Web staff client: > strings translated via staff client are displayed untranslated > https://bugs.launchpad.net/evergreen/+bug/1781641 Web Client: Cannot > Override Patron Message Block > https://bugs.launchpad.net/evergreen/+bug/1781235 Web Client: > Sometimes Unable to Change Primary Patron Barcode within "See All" Box > https://bugs.launchpad.net/evergreen/+bug/1746536 web client: cannot > edit vol/call number in item status > https://bugs.launchpad.net/evergreen/+bug/1745427 Web Client: Serials > - Predict New Issues Defaults to Previous Pattern > https://bugs.launchpad.net/evergreen/+bug/1552778 Web client check-in > "effective date" and check-out "specific due date" should also include > times > > Higher-effort > - > https://bugs.launchpad.net/evergreen/+bug/1511742 webclient: Need > ability to type to selection in some menus > > Patch exists, may need some tweaks > -- > https://bugs.launchpad.net/evergreen/+bug/1755258 webclient: LDAP not > working -- but works for stand alone client > > Overall, I think we can reasonably hope to resolve these over the next > couple weeks, although I specifically want to call out LP#1511742 as > the one bug that I think will require the most effort. > > Consequently, I am +1 for planning on disabling the XUL client in 3.2, > especially in light of plans for extending the support period for 3.1, > but do think that this decision needs to be evaluated and finalized at > the end of the upcoming bug-squashing week. > > Regards, > > Galen > > On Wed, Aug 29, 2018 at 11:57 AM Bill Erickson wrote: > >> Devs, > > > > I'd like to have an informal vote on whether we should remove (well, > disable) the XUL client in 3.2. Delaying the decision is complicating the > release process. If it's clear which way the wind is blowing, we can set a > date for the final vote and patching. > > > > Knowing what you know today about outstanding webstaff blockers (a few > were just added), would you vote to proceed with XUL removal? Can I get a > show of hands, yea or nay? > > > > Thanks, > > > > -b > > > > > -- > Galen Charlton > Implementation and Services Manager > Equinox Open Library Initiative > phone: 1-877-OPEN-ILS (673-6457) > email: g...@equinoxinitiative.org > web: https://equinoxInitiative.org > direct: +1 770-709-5581 > cell: +1 404-984-4366 >
Re: [OPEN-ILS-DEV] Informal vote to apply XUL-removal patch to 3.2
Based on what I know today, I reluctantly vote against removal. There are some bugs in that list with no other current workaround except to use the xul client to perform an action. I would happily change my vote in a couple of weeks if more progress were made on some of the webstaffblockers. Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128kluss...@masslnc.org On Wed, Aug 29, 2018 at 11:57 AM Bill Erickson wrote: > Devs, > > I'd like to have an informal vote on whether we should remove (well, > disable) the XUL client in 3.2. Delaying the decision is complicating the > release process. If it's clear which way the wind is blowing, we can set a > date for the final vote and patching. > > Knowing what you know today about outstanding webstaff blockers (a few > were just added), would you vote to proceed with XUL removal? Can I get a > show of hands, yea or nay? > > Thanks, > > -b > >
Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] 3.2 feature freeze and more
Hi Bill, In looking at the list of showstoppers, I see one has a pullrequest, so it seems reasonable it could be tested and merged soon. For the other bugs, does anyone have a sense of whether any are particularly complex? Or are they mostly straightforward bugs that just haven't been addressed yet due to lack of tuits? If it's the latter, could we consider delaying the full release (with xul removal) until the showstoppers are fixed? I'm concerned about the breakage that is likely to occur the longer we continue to make the xul client available in our releases, but these bugs were identified as real issues in getting libraries to adopt the web client. At this time, there are just a handful of remaining showstoppers, and if we can commit to getting them resolved before the full release, I think it will make a smoother transition to 3.2 for our libraries. Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128kluss...@masslnc.org On Mon, Aug 27, 2018 at 6:47 PM Bill Erickson wrote: > Hi Scott, > > On Mon, Aug 27, 2018 at 5:24 PM scott.tho...@sparkpa.org < > scott.tho...@sparkpa.org> wrote: > >> Hi Bill, >> >> I have two questions about this: >> >> >> >> 1. You mentioned a vote. Who is the “we” that votes? >> > Good question. This would be a core developer vote. I started typing > this as a developer list message, then added the general list just before > sending... > > From my perspective, this vote is more about getting a public record of > developer buy-in (or otherwise) as is typically the case before proceeding > with a large architectural change. It also acts as a "should we do this?" > safety valve. However, I call the vote now because in my opinion as RM we > are ready to proceed and I suspect that's what we'll decide. It's not done > 'til it's done, though. > > It's also worth reminding everyone we are also providing extended support > for Evergreen 3.1, so users can continue using the XUL client for a longer > period of time. Normally, a release is supported for 12 months of bug > fixes, plus 3 months of security fixes. 3.1 will be supported for a longer > period of time -- duration TBD -- so sites will have more time before > needing to upgrade to 3.2. This will buy us more time in the community to > continue squashing bugs as well. > >> 2. If it is determined that not enough blockers are fixed, does >> this mean that a 3.2 version of XUL will be made available and XUL will not >> be removed until 3.3 >> >> Yes, if the core developers vote not to proceed with XUL removal, it > would be delayed until the next release cycle (3.3). > > Just to offer some perspective, from the dev side it's not just a question > of how many web staff blockers remain, but how much work is required to > resolve each, who can sign up to fix them, how many sites they likely > affect, how much developer time will be siphoned away from fixing these > issues trying to maintain XUL in 3.2 (!), the fact the XUL is already a > little bit broken in 3.2 based on the agreement it would it would be > removed, etc, etc. > > Thanks, > > -b > > >
Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] 3.2 Notes on browser client settings moving to server
Hi Bill, 2. A workstation setting can be turned into a user setting by creating a > matching user setting type (same setting name) and removing the workstation > setting type. Such settings will follow the logged user account instead of > the workstation. Can we assume the opposite is true too? While testing, I was thinking that some sites may prefer the copy templates to be a workstation setting instead of a user setting. Thanks for your work on this! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128kluss...@masslnc.org On Fri, Aug 3, 2018 at 2:23 PM, Bill Erickson wrote: > Hi All, > > With special thanks to Kathy Lussier (and Chris Sharp), > https://bugs.launchpad.net/evergreen/+bug/1750894 was merged to master > today. This change moves persistent browser client preferences / settings > out of the browser (localStorage / Hatch) to the server. With this, > preferences and settings will persist across browser sessions and be > shareable across multiple browsers. Clearing localStorage will no longer > delete preference values. > > This code will impact administration and development of new features. I > wanted to review some of those here since it might impact active > development. > > Developers > > 1. New browser client settings/preferences that should persist across > browser sessions require a DB upgrade script to add the needed rows to > config.worksation_setting_type. > > 2. Settings that should only be stored locally (e.g. last retrieved > patron) should be stored using hatch.setLocalItem / getLocalItem or the key > prefix should be added to the list of special prefixes in hatch.js => > service.browserOnlyPrefixes. > > 3. Beware that storing preferences on the server means more API calls are > needed to load the data. Whenever possible, make use of the > hatch.getItemBatch call to condense lookups into fewer API calls. > > Admins > > 1. Migration from browser storage to server storage should happen > seamlessly as each setting is accessed using the new code. > > 2. A workstation setting can be turned into a user setting by creating a > matching user setting type (same setting name) and removing the workstation > setting type. Such settings will follow the logged user account instead of > the workstation. > > 3. No setting can be both a workstation and user setting. They are > mutually exclusive. > > 4. Org settings with the same name as a user/workstation setting act as a > fall-through value. > > 5. Org setting types that match a browser preference/setting where no > user/workstation setting type exists (or has been deleted) act as a > read-only configuration for the setting. This can be useful, for example, > for applying a grid display configuration that cannot be changed by staff. > > There are more UI improvements to make for this feature, especially for > managing org unit settings, but I wanted everyone to be aware the pieces > are in place to do these things on the back-end. > > -b > > >
Re: [OPEN-ILS-DEV] Bug Squashing Week Results
Thank you, Terran, for coordinating a very successful bug squashing week! I'm very excited about all of the web client bug fixes available in the latest Evergreen release! Kathy On 05/29/2018 11:00 AM, Terran McCanna wrote: Last week's Bug Squashing Week saw a record number of participants and a whopping 18 new bug patches submitted, 231 feedback comments, and 32 patches committed!!! The final chart is here: https://docs.google.com/spreadsheets/d/1pKdrHjwWpuQY-F0wGrIew5I65tAM4NxOZJfpJL33vDk/edit?usp=sharing And the Evergreen web page has been updated here (scroll down): https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing An enormous thank you to everyone involved! The next Bug Squashing Week will be scheduled for late Summer. Terran McCanna PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, GA 30345 404-235-7138 tmcca...@georgialibraries.org <mailto:tmcca...@georgialibraries.org> -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Dev meeting at the conference
Hi, I need to be in the exhibit hall during the break, but feel free to assign me to anything for the developers update. Except karaoke. Kathy On 05/01/2018 03:48 PM, Galen Charlton wrote: Hi, I would like to call a brief in-person meeting tomorrow (Wednesday), say during the 3:20 p.m. afternoon break, to work out who is going to be doing what during the developers' update Thursday morning. Let's meet by the conference registration desk. Regards, Galen -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Fast Item Add
Hi Justin, It appears as if this is a known bug in the xul client when the unified volume/copy editor is enabled. https://bugs.launchpad.net/evergreen/+bug/1559273. Since the xul client is officially deprecated as of 3.0, it is unlikely it will get fixed. I haven't checked the new web client to see if this bug still exists there. Good luck with the upgrade! Kathy On 02/13/2018 07:20 PM, Justin Wynn Goold wrote: Hi All, I’m in the process of trying to upgrade from Evergreen 2.1.0 to 3.0.2, and I have one remaining problem in my test environment that I’ve been unable to work through. When doing a z39.50 import, if I do a “Fast Item Add” in the MARC Editor, I get the “Record successfully imported” alert, but the Volume and Copy Creator window doesn’t come up. I’m taken straight to the Bib Record instead. If I then choose “Actions for this Record” >> “MARC Edit” and do the “Fast Item Add” again, things work as expected. With OpenSRF logging set to 4, I see two INSERT statements during the initial “Fast Item Add” process, one to biblio.record_entry, and one to asset.call_number. I have no errors in the log after that. Can anyone point me in the right direction? Many thanks. Justin -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Evergreen developers meeting tomorrow
Hi all, We have an Evergreen developer's meeting scheduled for tomorrow at 12 p.m. Pacific, 3 p.m. Eastern, 20:00:00. A draft agenda is available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2018-02-06. Feel free to update it if you have anything you want to discuss. Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Olly olly oxen free - upgrade updates
Hi, - chatter about adjustments for record reingest I don't know if this is what you're referring to, but there's been some chatter about dropping triggers for the 1057 upgrade script. I know csharp has a branch he's been sharing when people have been testing the upgrade. I don't think anyone has submitted anything to LP on it. Also, do we need to include an authority reingest in the upgrade script for the MADS work? Kathy On 09/26/2017 10:55 AM, Galen Charlton wrote: Hi, In preparation for the release candidate tomorrow, I am sending out a call for changes needed for the installation and upgrade process, particularly the schema update. I'm aware of the following so far: - a change in the works by Mike to sync up the base schema and schema updates for action.fieldset_group - chatter about adjustments for record reingest Regards, Galen -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Proposed XUL bugfix merge policy for 3.0 and beyond
+1 from me too, with a couple of follow-up questions/comments: Of course, a strict interpretation of this policy presumes that showstopper issues with the web staff client are addressed by 3.0.0, or at least early in the 3.0.x maintenance release cycle. This was briefly discussed during yesterday's meeting, but to properly identify these showstopper issues, should we be setting showstopper web client bugs to a priority of 'high' in Launchpad? Or is there another way we should be identifying them? A further implication is that if you want to get a particular XUL-only bugfix into Evergreen, you have until the 3.0.0 release candidate is cut on 27 September to get it in. I recently used a xulclient tag for bugs with a pullrequest tag where the fix only applied to the xul client. I thought it would be useful for identifying these bugs during the Feedback Fest where quicker action might be needed so that they are merged before the 3.0 release. There were only two bugs at the time, and one has since been merged. If future XUL-only bug fixes are submitted, it might be useful to use this tag to bring some attention to the bug before the September 27 cutoff. Thanks Galen! On 08/03/2017 11:32 AM, Jason Etheridge wrote: +1 from me as well :) -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Evergreen dev meeting tomorrow
Hi all, We have a developer's meeting scheduled tomorrow for 3 p.m. Eastern, 12 p.m. Pacific, 20:00:00 UTC. I have posted a draft agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-08-02. Please feel free to add any agenda items you may have. Thank you! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Evergreen 3.0 installation and Gentoo packages
Hi Graham, I'll let others answer most of your questions, but in answer to your first question: First question: Are git://git.evergreen-ils.org/OpenSRF.git and git://git.evergreen-ils.org/Evergreen.git the repositories for Evergreen 3.0 and the associated version of OpenSRF? git://git.evergreen-ils.org/Evergreen.git is the master version of Evergreen which will eventually become Evergreen 3.0. However, there is no Evergreen 3.0 yet and there won't be one until September when the beta version of 3.0 is scheduled to be released. You certainly can run Evergreen master rather than an official release - I've known a couple of other systems that have done so in the past. However, I also wanted to point out that you can run the 2.12 release with the web client. There is no need to use the xul client on the 2.12 release if that is your primary reason for looking at 3.0. Whatever direction you choose, good luck with your trials! Kathy On 07/10/2017 09:36 PM, Graham Billiau wrote: Hello I've started trialling Evergreen 3.0 for managing a private library. We previously tried Evergreen 2 but the XULRunner based staff client didn't work for us. It's a small library with only a couple of customers, so we're happy to risk beta software. First question: Are git://git.evergreen-ils.org/OpenSRF.git and git://git.evergreen-ils.org/Evergreen.git the repositories for Evergreen 3.0 and the associated version of OpenSRF? Second: My server runs Gentoo Hardened linux. Has anyone written Gentoo ebuilds for Evergreen? Similarly, has anyone written SELinux profiles for OpenSRF and Evergreen? If not, I'll write them myself. Third: Assuming I have to write the ebuilds and profiles myself, is anyone else interested in them? If they are I can do them neatly and make them available. Forth: Are there any extra steps beyond the standard upgrade instructions for migrating old data to Evergreen 3? I can't remember which specific version we last tried, but it would be good to keep that data. Thanks for your help Graham -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Today's developers meeting
Hi all, Dyrcona and I were just talking in IRC about today's scheduled developer's meeting. Since the meeting agenda hasn't been sent out yetand there may be some people unavailable due to vacations around the U.S. Fourth of July holiday, we were thinking it might be best to cancel or reschedule the meeting. Do people have business to discuss that would warrant rescheduling the meeting for later in the month or should we just plan on meeting next on August 2? The only item of business I had to discuss was the Core Infrastructure Initiative Badge Program (http://markmail.org/message/clei6p57ok4jcouu), but there's no reason it can't wait until August or even just get discussed via email. If we do want to reschedule for later in July, I can send out the Doodle poll. Thank you! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Core Infrastructure Initiative Badge Program
Hi all, A while ago, I came across the Core Infrastructure Initiative Badge Program, which awards a badge to open source projects that follow a set of best practices that shows the project's commitment to security. According to their web site (https://www.coreinfrastructure.org/programs/badge-program): " The Core Infrastructure Initiative (CII) Badge Program is a free program designed with the open source community with criteria that evolves to allow for compensating controls rather than a strict mechanical process. The Best Practices Badge is an open source secure development maturity model. Projects having a CII badge will showcase the project's commitment to security." I wanted to see if there was interest in investigating what steps would need to be taken to earn a badge for the Evergreen project. The criteria for the badge is available at https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md. Scanning through the list, I see many criteria that we are already meeting. I have a couple of reasons for wanting to pursue this badge: - Running through the criteria list should be a useful exercise that will help us see what the strengths of our project are and where we need to improve. If we focus on improving the areas where we don't initially meet the criteria, it will help to strengthen our project. - If we earn a badge, it can provide assurance to our users and to prospective users that we are a mature project that is following best practices identified by the open-source community as preferred standards. The badge is evidence that we do indeed follow recommended quality assurance practices and are committed to providing secure software. If there is interest, maybe a few of us can divide up the list of criteria to identify ones we are already meeting and ones that we need to work on. Let me know what you think. Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] June bug squashing week?
Hi Terran, I'm fine with whatever decision is made. However, I was just re-reading Galen's update from the last feedback fest - https://evergreen-ils.org/evergreen-3-0-development-update-6-feedback-fest-results/ - and noted that the people who participated in the feedback fest are a different group than those who normally participate in the Bug Squashing events. I know the Feedback Fest is open to all just as Bug Squashing Day is, but I think if you do decide to proceed with Bug Squashing Day, you're likely to get some people who might not be involved in the other activity. Kathy On 06/07/2017 01:26 PM, Terran McCanna wrote: Hi everyone, I had planned for a bug squashing week for June 19-23, but since the web client bug squashing has been so intensive lately and since Galen recently had a web client feedback fest and then has another one scheduled for August 7-11, I wonder if this June session is overkill. Please respond to me off-list if you would plan to participate if I go forward with it. Thank you! Terran McCanna PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, GA 30345 404-235-7138 tmcca...@georgialibraries.org <mailto:tmcca...@georgialibraries.org> -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Agenda for conference hackfest
HI all, I've started an agenda for next week's hackfest and posted it to the wiki at https://wiki.evergreen-ils.org/doku.php?id=dev:hackfest:eg2017 Feel free to add any topics you want to discuss or projects you plan to work on! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Tomorrow's RM Election
Hi, I agree that we should continue with our plan to meet tomorrow and should also hold a vote as we've done for past RM elections where this is only one candidate. With that in mind, I'll open up the floor to questions for Galen when I start the meeting, with discussion of the release goals. As a reminder, Everyone is invited to participate in the voting. Evergreen core committers who cannot make the meeting may submit their vote via email to the open-ils-dev mailing list. Thank you! Kathy On 03/27/2017 06:04 PM, Galen Charlton wrote: Hi Dan, I suspect we have different views on the role of competition in certain community decisions, but I'm sure that we both would have approached the vote in a spirt of fair play and with no hard feelings, regardless of the outcome. Nevertheless, I respect your decision and look forward to working with you and the entire Evergreen development community towards what will be the best release of Evergreen yet this fall. I suggest that folks plan on touching base tomorrow at 1 p.m. EDT in #evergreen anyway to discuss plans for 3.0 and confirm that we're all on more or less the same page regarding release goals. Regards, Galen On Mon, Mar 27, 2017 at 2:18 PM, Daniel Wells wrote: Hello all, Since our project adopted the idea of "release managers" in 2012, we have managed to select each by consensus. While we typically had elections, the nominees until now have always run unopposed. I find this tradition to be a beautiful thing, and one I would like to see preserved for as long as possible. As such, I am withdrawing myself from consideration for the RM role for 3.0. While I believe strongly in the value of competition, I feel that unity is of even greater value for a community of our size. I hope instead that I might be considered for management of the 3.1 release. It seems that my vision for the 3.0 release is perhaps better suited for a 3.1 release in any case. Sincerely, Dan -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Reminder: Deadline for RM nominations is Friday
Hi all, I'm sending along a reminder that nominations (including self-nominations) for 3.0 Release Manager are due by 11:59 p.m. EDT on Friday, March 24. Nominations should be made by email to open-ils-dev@list.georgialibraries.org with a Cc: to open-ils-gene...@list.georgialibraries.org. Replying to all on this email will also work. Nominees should send an email to both of the above mailing lists a statement about their relationship to the Evergreen community and their goals for the next release. The elected release manager is expected to adhere to the established schedule for the release milestones. The Release Manager does not have to be a core committer, but does need to be familiar with Git and have already contributed substantially to the Evergreen project whether it be code or documentation. Elections will be held next week in the #evergreen IRC channel on the freenode network. If you are planning to vote in the election, please be sure to fill out the Doodle poll at http://doodle.com/poll/dhsdx4vdr3qw2r2z so that we can determine a date for the election. Thank you! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Postgres requirements for 2.12 and 3.0
Hi Jason, +1 from me on keeping support for Wheezy and Trusty through release 3.0. Since I heard no other objections to the recommendation, I'm going to update release notes and other documents with the recommendation to use 9.4. I'll also send out a message to the general list with this information. Thank you! Kathy On 03/02/2017 10:10 AM, Jason Stephenson wrote: I have no issues with it. I just wanted to add that Ben Shum and I have been working on making Pg 9.4 the defaults for new installs with Ubuntu 14.04 Trusty Tahr and Debian 7 Wheezy. This is based on work started by Chris Sharp. See https://bugs.launchpad.net/evergreen/+bug/1493824 In general, I don't think sites should be doing new installs with Trusty and Wheezy, but we still have issues with some lesser-used bits of Evergreen on Ubuntu 16.04 Xenial Xerus and Debian 8 Jessie. We also keep the latest two LTS releases of Ubuntu and the latest two releases of Debian available in the Makefiles. We should keep them up to date since they are there. For reference Debian 7 Wheezy has LTS from the Debian community until May 2018. Ubuntu 14.04 Trusty Tahr has LTS from Canonical and the community through April 2019. These dates coincide rather closely with the end of life dates for Postgres 9.4 and Evergreen releases 2.12 and 3.0. I am trying to make the preemptive case for keeping support for Wheezy and Trusty in mainline Evergreen through release 3.0 with PostgreSQL 9.4 as the baseline database. Cheers, Jason -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Postgres requirements for 2.12 and 3.0
Hi all, At today's developers meeting, we discussed minimum Postgres requirements for the 2.12 and 3.0 Evergreen releases. Those attending the meeting would like to make the following recommendations for Postgres support. For the 2.12 release, deprecate Postgres 9.3 support and recommend use of Postgres 9.4. For the 3.0 release, make Postgres 9.4 a minimum requirement. A primary reason for this recommendation is related to an upcoming development project that will require Postgres 9.4 features. This project is expected to be ready for the 3.0 release. Equinox is currently working on a development project to improve Evergreen search (more information on this project in an earlier e-mail at http://markmail.org/message/4styymc3asioa5yl). The goal of this work is to eliminate two-stage search from Evergreen, leading to a more complete set of search results. Early analysis has also shown that, after this work is done, searches should be as fast or faster than the existing code base, with the biggest performance gains seen with more selective searches. This project requires the use of database functions only available in Postgres 9.4+ Also note the following end of life dates that are coming up with Postgres and Evergreen releases. Postgres 9.3 end of life date: September 2018 Postgres 9.4 end of life date: December 2019 Evergreen 2.12 end of life date: March 2018 Evergreen 3.0 end of life date: September 2018 Postgres 9.4 has been in release since December 2014 and is already used successfully in production at many Evergreen sites. The new requirements would not impact any Evergreen releases prior to the 2.12 release. We had a light attendance at the dev meeting when we discussed these requirements. We therefore wanted to throw this recommendation out to the list before firming it up. If you have any questions or concerns about the recommendation, please send a response to the list by the end of the day Friday. Thank you! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Dev meeting tomorrow
Hi all! We have a dev meeting scheduled for tomorrow at 12 p.m. Pacific, 3 p.m. Eastern, 20:00 UTC. The draft agenda is available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-03-01. Feel free to add topics to the agenda before the meeting. Would anyone like to volunteer to facilitate the meeting? Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Upcoming 2.12 release
Hi all, Galen brought to my attention that I had an incorrect date in my earlier e-mail on the release schedule. Beta freeze is end of the day Friday, February 17, not the 10th. Sorry for the confusion! We still have a few days, then, to test and merge code that is targeted to 2.12. The list of branches that need review have decreased, but we still have several feature branches that could use review - http://bit.ly/2lPdChU There are a few 2.12-targeted bugs without code, and I have been in communication with the developers working on those bugs. I'll be following up today to see where things stand. In particular, I would like to highlight the following branches where I could use help with review (most are repeats from my last e-mail): - Incorporating part information into biblio fingerprint - https://bugs.launchpad.net/evergreen/+bug/1553287 - This is one of two bugs that propose changing the way biblio fingerprints are generated. I would like to merge them at the same time so that sites only need to regenerate fingerprints once. Since I wrote the code to incorporate part information, I need somebody else to sign off on it before both branches can be merged. - Evergreen integration with obalkyknih.cz - https://bugs.launchpad.net/evergreen/+bug/1624366 - many thanks to Jason Stephenson for providing initial review of this code last week! The branch has been re-worked and is ready for review again. - Add get_org_unit_ancestor_at_depth to action trigger reactor helpers - https://bugs.launchpad.net/evergreen/+bug/1661747 Although I will be reviewing the following branch, due to the complexity of holds in Evergreen, I would welcome additional eyes on the code: https://bugs.launchpad.net/evergreen/+bug/1596595 - Hold targeter features and refactoring- Many thanks to Chris Sharp for providing an initial signoff on this code after running it in production. Feel free to let me know if you have any questions! Kathy On 02/08/2017 08:32 AM, Kathy Lussier wrote: Hi all, Thanks to everyone who applied the 2.12beta targets to their bugs and who talked with me over the past few days on the status of their code. We have many LP bugs now with the 2.12 target applied - http://bit.ly/2kSdVdG. At this time, I'm putting out a general call to core committers and other testers to help with testing the branches. For now, we should focus on branches that are new features so that we can merge them in time for the beta freeze on Friday, February 10. I have a lot of time carved out to test these branches, but the more people who are involved in testing, the greater the likelihood that all of these patches can be reviewed. In particular, I could use help with reviewing the following patches: https://bugs.launchpad.net/evergreen/+bug/1624366 - This is a new feature that would add integration for the Czech Added Content provider, obalkyknih.cz. https://bugs.launchpad.net/evergreen/+bug/1649180 - Adds a new 'translator' make target option https://bugs.launchpad.net/evergreen/+bug/1553287 - Incorporating part information into biblio fingerprint - I need a signoff on this one so that I can merge it along with another, already-signed-off branch that also updates biblio fingerprint. I have been reviewing the below two branches, but would welcome additional review from another developer on them: https://bugs.launchpad.net/evergreen/+bug/1629108 - Metarecord constituents search result page should use standard search code. Note: this one already has a signoff from me https://bugs.launchpad.net/evergreen/+bug/1573734 - Link to sibling metarecord bibs in record details - This one is almost ready to go, but Blake is seeking additional feedback on one piece of the project. We already have people looking at the below two branches, but the changes are significant and probably should get broad review: https://bugs.launchpad.net/evergreen/+bug/1596595 - Hold targeter features and refactoring https://bugs.launchpad.net/evergreen/+bug/1646166 - Hatch 2.12 Omnibus - this one is a high priority for production use of the web client. I also want to make note of a couple of requirements for the release: I plan to merge https://bugs.launchpad.net/evergreen/+bug/1005040 sometime this week. Because it requires OpenSRF 2.5, we will need to update our minimum OpenSRF requirement for the 2.12 release. We also have a couple of branches targeted for 2.12 that will require a reingest. Thanks in advance for all of your help! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Upcoming 2.12 release
Hi all, Thanks to everyone who applied the 2.12beta targets to their bugs and who talked with me over the past few days on the status of their code. We have many LP bugs now with the 2.12 target applied - http://bit.ly/2kSdVdG. At this time, I'm putting out a general call to core committers and other testers to help with testing the branches. For now, we should focus on branches that are new features so that we can merge them in time for the beta freeze on Friday, February 10. I have a lot of time carved out to test these branches, but the more people who are involved in testing, the greater the likelihood that all of these patches can be reviewed. In particular, I could use help with reviewing the following patches: https://bugs.launchpad.net/evergreen/+bug/1624366 - This is a new feature that would add integration for the Czech Added Content provider, obalkyknih.cz. https://bugs.launchpad.net/evergreen/+bug/1649180 - Adds a new 'translator' make target option https://bugs.launchpad.net/evergreen/+bug/1553287 - Incorporating part information into biblio fingerprint - I need a signoff on this one so that I can merge it along with another, already-signed-off branch that also updates biblio fingerprint. I have been reviewing the below two branches, but would welcome additional review from another developer on them: https://bugs.launchpad.net/evergreen/+bug/1629108 - Metarecord constituents search result page should use standard search code. Note: this one already has a signoff from me https://bugs.launchpad.net/evergreen/+bug/1573734 - Link to sibling metarecord bibs in record details - This one is almost ready to go, but Blake is seeking additional feedback on one piece of the project. We already have people looking at the below two branches, but the changes are significant and probably should get broad review: https://bugs.launchpad.net/evergreen/+bug/1596595 - Hold targeter features and refactoring https://bugs.launchpad.net/evergreen/+bug/1646166 - Hatch 2.12 Omnibus - this one is a high priority for production use of the web client. I also want to make note of a couple of requirements for the release: I plan to merge https://bugs.launchpad.net/evergreen/+bug/1005040 sometime this week. Because it requires OpenSRF 2.5, we will need to update our minimum OpenSRF requirement for the 2.12 release. We also have a couple of branches targeted for 2.12 that will require a reingest. Thanks in advance for all of your help! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Reminder: Monday is 2.12 feature slush
Hi all, I'm sending along a reminder that Monday is feature slush day. If you have a new feature you would like to see in the Evergreen 2.12 release, you should have LP bugs with the 2.12beta milestone applied, a link to a git branch, and, ideally, a pullrequest tag. If it's not ready for a pullrequest tag, but is close to complete, please post the link to the git branch and give me a heads up on where you are with the project. The feature freeze is still two weeks away (February 17), so we still have a wriggle room for testing, but the later the pullrequests tags are added, the less likelihood that branches will make it into 2.12. Feel free to let me know if you have any questions! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Rescheduling January dev meeting
Hi all, The January dev meeting has been scheduled for Tuesday, January 10 at 1 p.m. Eastern, 10 a.m. Pacific. The draft agenda is available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-01-10 Feel free to add any discussion items to the agenda. Have a nice weekend! Kathy On 01/04/2017 02:59 PM, Kathy Lussier wrote: Hi all, Happy New Year! We have a dev meeting on the calendar scheduled to start in two minutes, but as an agenda wasn't sent out to the list ahead of time, we decided in IRC to reschedule it for next week. Please fill out the Doodle poll at http://doodle.com/poll/esxgzfum2cwkbv7v to let us know when you're available to meet. Also, feel free to add agenda items here - https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-01-04. I'll update the link and date information once a new date has been set. Thank you! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Rescheduling January dev meeting
Hi all, Happy New Year! We have a dev meeting on the calendar scheduled to start in two minutes, but as an agenda wasn't sent out to the list ahead of time, we decided in IRC to reschedule it for next week. Please fill out the Doodle poll at http://doodle.com/poll/esxgzfum2cwkbv7v to let us know when you're available to meet. Also, feel free to add agenda items here - https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-01-04. I'll update the link and date information once a new date has been set. Thank you! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] December dev meeting is tomorrow
Hi all! We have a developers meeting scheduled for tomorrow at 12 noon Pacific / 3 p.m. Eastern. I have created a draft agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2016-12-07. Feel free to add any discussion items to the agenda. If you have a development project for which you would like feedback from the other developers, feel free to add it to the "Feedback for New Features Under Development" portion of the agenda. Would anyone be willing to volunteer to run this meeting? Thanks! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Proposed 2.12 release schedule and call for Roadmap entries
Hi all, Below is my proposed schedule for the 2.12 release. I suggest that we forgo the alpha release since it typically doesn't get much testing. However, I would like to see if we can get more people involved in testing the release once beta is out. Monday, February 6 - feature slush - all significant features should have LP entries and pullrequests Friday, February 17 - feature freeze Wednesday, February 22 - beta release Wednesday, March 15 - rc1 release Wednesday, March 22 - .0 release I'll let the dates sit out there for community feedback over the few couple of days before adding them to the developers calendar. At this time, I would also like to put out a call for Roadmap entries for the release. If you are planning to build or fund a significant enhancement in time for the February 6 feature slush, please add it to the 2.12 Roadmap page at https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:2.12 You can also e-mail me directly to add a feature to the Roadmap. Although I expect people will be updating the Roadmap as we get closer to the release, please try to add any features you know about now to the map by November 23. Feel free to let me know if you have any comments or questions! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] Call for Release Manager nominations — Evergreen.next
Hi all, I would like to submit my name for consideration to be Release Manager for Evergreen 2.next. I have worked in the Evergreen community for more than six years, contributing both code and documentation to the project and reviewing contributions made by others. I have also been active in developer meetings and helped organize Bug Squashing Days. Through my involvement, I have a good handle on the planning, communication and organization required for a smooth release process. I have one primary goal for the next release: getting the browser-based client closer to a finished state so that more libraries are able to run it in a production environment. During next week's hack-a-way, we have an agenda item to discuss a path to completion and a release of 3.0 in 2017. Regardless of whether this discussion leads to a 3.0 release in March or not, I think focusing on a few key areas can put us in a position where more libraries will be able to start using the web client with the next release. Reaching this goal will require the help and participation of all contributors to the project, not just developers, but also DIG members, testers and those who are experts in the Evergreen application. Here are some of the areas I would like to focus on over the next few months: ADDRESSING KNOWN BUGS Despite the extensive amount of testing and bug fixing that has occurred as each sprint has been completed, continued testing has turned up more bugs in the web client, something that is to be expected with a project this large. Although some of these bugs are small, others may be blockers for libraries to start using the new client. Over the past few weeks, there has been a lot of activity in fixing the bugs, but it would be great if we could get more involvement from the developer community to work on them. We are likely to learn of more bugs once libraries use the web client in production, and clearing out the known ones now will help the process go a little more smoothly. To help us focus on these bugs, I would like to follow up on a suggestion I think first came from Galen and Mike to schedule web client hacking days in the community. Ideally, some of the developers who have worked extensively on the web client would be available to answer questions on those days, but I think the real benefit lies in setting aside the time where code contributors can focus on working on those bugs. ADDRESSING LOW-HANGING UI AND CONSISTENCY ISSUES Another area I would like to focus on is addressing UI and consistency issues in web client. This work could include: - identifying inconsistent language in the new client and then providing more consistency in these areas. - in web client grids, ensuring that default column picker options reflect the data staff most often need to see. - identifying and improving other low-hanging usability issues DOCUMENTATION Web client hacking days don't just need to be for code contributors. As we get closer to a full web client release, fully documenting the new interfaces is becoming more critical. I welcome any other ideas you all may have for getting the web client ready for our Evergreen libraries! Thank you for your consideration. Kathy Lussier On 10/17/2016 09:57 AM, Galen Charlton wrote: Hi, It is fast approaching time to elect the Release Manager for the next Evergreen release. The Release Manager does not have to be a core committer, but does need to be familiar with Git and have already contributed substantially to the Evergreen project whether it be code or documentation. Nominations (including self-nominations) are due by 11:59 PM EDT on Friday, 28 October. Nominations should be made by email to open-ils-dev@list.georgialibraries.org with a Cc: to open-ils-gene...@list.georgialibraries.org. Replying to all on this email will also work. Nominees should send an email to both of the above mailing lists a statement about their relationship to the Evergreen community and their goals for the next release. The elected release manager will be expected to adhere to the established schedule for the release milestones. The election will be held in the Evergreen IRC channel on freenode.net during the week of October 31st (i.e., the week of the Evergreen Hack-a-way). Later this week, I will circulate a poll for setting the specific date and time. Everyone is invited to participate in the voting. Evergreen core committers who cannot make the meeting may submit their vote via email to the open-ils-dev mailing list. As a side note, during the Hack-a-way we will discuss the results of the experiment with the buildmaster position during the 2.11 cycle; if we decide to continue with it, we'll likely select buildmasters for the next release during the Hack-a-way or shortly thereafter. Regards, Galen -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.or
Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] Bug Squashing Day Report
Many thanks to you, Terran, for organizing the day. By all accounts, it looks like it was a great success! Kathy On 10/04/2016 02:18 PM, Terran McCanna wrote: I've posted a summary of the results of Bug Squashing Day at: https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing:2016-09-29 The tracking sheet is available at: https://docs.google.com/spreadsheets/d/1DOQ49RsDm_6InRvYovx9QpJY_v8F33vA9ZIFmtRmlMs/edit?usp=sharing An enormous "Thank you!" to everyone who participated, and additional thanks to Kathy Lussier and Blake Henderson for providing sandboxes for testing! (If I've left anyone off, please let me know and I'll update the pages.) Terran McCanna PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, GA 30345 404-235-7138 tmcca...@georgialibraries.org <mailto:tmcca...@georgialibraries.org> -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] October Developers meeting next week
Hi all, We have an October developers meeting scheduled for Wednesday, October 5, at 12 noon Pacific, 3 p.m. Eastern. I've posted a draft agenda for the meeting at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2016-10-05. Please feel free to add discussion items to the agenda. Thank you! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Bug Squashing Day Today!
Hi all, I've loaded some of the patches submitted today on a Sandbox in case anyone wants to test them before Bug Squashing Day ends. All of these patches should be fairly quick and easy to test. https://bugs.launchpad.net/evergreen/+bug/1623134 KPAC - "Get It!" page does not show item status Edit https://bugs.launchpad.net/evergreen/+bug/1629075 Hide Permalink in Client Edit https://bugs.launchpad.net/evergreen/+bug/1628966 View Temporary/My Lists from Record Summary Edit https://bugs.launchpad.net/evergreen/+bug/1623955 Subject links in the catalog inappropriately strip periods from search string Edit The server access information is below: Server URL: https://mlnc4.noblenet.org Download Client URL: https://mlnc4.noblenet.org/updates/manualupdate.html Admin login: admin / evergreen123 (You may need to add an SSL exception to log in successfully) Login information for other user accounts is available at https://wiki.evergreen-ils.org/doku.php?id=qa:concerto_logins. If you test any of these patches and find a problem, please feel free to share your results on the appropriate LP bug. If the code is working as expected for you, you can sign off on it as described in the Bug Squashing Day guidelines at https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing#testing_bugs Many thanks to Terran for organizing another great day! Kathy On 09/29/2016 09:09 AM, Terran McCanna wrote: Good morning everyone, and Happy Bug Squashing Day! I will be watching Launchpad today and noting all of your new bug reports, test confirmations, code submittals, and bug feedback and tracking them on this chart: https://docs.google.com/spreadsheets/d/1DOQ49RsDm_6InRvYovx9QpJY_v8F33vA9ZIFmtRmlMs/edit?usp=sharing An enormous thank you to Kathy Lussier of MassLNC and Blake Henderson of MOBIUS for creating sandboxes for everyone who requested them!! Terran McCanna PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, GA 30345 404-235-7138 tmcca...@georgialibraries.org <mailto:tmcca...@georgialibraries.org> -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Ruby gem for accessing holdings + availability information
That's great Jane! Thanks for sharing it with the community. Kathy On 09/28/2016 01:16 PM, Jane Sandberg wrote: Hi all, I have put together a small Ruby gem that helps get real-time availability from Evergreen ILS. The primary use case I had in mind is for Blacklight-based discovery layers that want to get copy/availability information to their patrons, but I'm sure there are other uses as well. My git repo is here: https://github.com/sandbergja/evergreen_holdings_gem And the gem is available on RubyGems as well. Its name is not very creative: it's 'evergreen_holdings'. I am planning to add more documentation and tests as I have time. I am also very happy to hear your feedback, feature requests, and pull requests. Let me know if you have any questions! -Jane -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Acknowledgements and Release Notes
Hi all, I've had a long-standing item on my to-do list to document the process of being the DIG Release Coordinator, mainly so that I can pass the role on to somebody else, but also so that the process is transparent to the rest of the community and provides opportunity for feedback. It's also helpful for times when the RM's take the responsibility for creating release notes when the DIG Release Coordinator is unavailable. I finally started documenting the process this week, and I started a bit backwards by documenting how we determine whom to acknowledge in the release notes. I rarely get questions about the release notes themselves, but I have fielded several questions about who is being acknowledged in release notes. The idea is to thank everyone who has played a part in the release, no matter how small that part may seem to the contributor, and to also highlight the rich and diverse community that makes an Evergreen release happen. I try to err on the side of inclusion in the acknowledgements if there is a question because it's important we give credit to everyone behind the release process. Acknowledgements were added to the release notes back in the 2.6 release with a contribution from Galen. I can't say how he identified contributors for that release, but I can say that in my early acknowledgements, I added the names of any author for a documentation or code commit that was in a particular release branch, whether it was a bug fix or new feature. It was fairly straightforward. Since that time, we've added people who should be acknowledged, the most recent addition for the 2.11 release being people who contribute to translations. The method for identifying translators for a specific release is imperfect, but it's important that we do our best to acknowledge these folks since they do so much to help promote the international use of Evergreen. The addition of point release notes back in the 2.8 release changed the way I identified contributors for a specific release. In the beginning, I wasn't planning to add acknowledgements for bug fixes to the point release notes because I knew those contributions would be acknowledged at the point of the major release. However, in the release notes that are linked on the main Downloads page, which, FWIW, look a lot different than the notes in the official documentation, it was confusing. The acknowledgements appeared to refer to all of the new features and bug fixes on that page, including the ones that were part of point release notes. However, the names were only for people who contributed to the major release. There was a disconnect. As a result, my current practice is to acknowledge all bug fix contributions and backported documentation patches in the point release notes, not in the notes for a major, feature release. The major release acknowledgements focus on the contributors for the new features only. I've documented the current practice for acknowledgements at https://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:release_notes_process. I'm sharing this with all of you because I would like feedback from developers and DIG contributors on the following questions: - Does the process for identifying who should be acknowledged for code and doc contributions in major release vs. point releases seem reasonable to people? - Is there anyone contributing to releases that we're missing in our acknowledgements? - Are there any other changes you think should be made? If we decide to change these guidelines, I'm happy to make the necessary changes to the 2.11 notes. Thanks in advance for your feedback! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Android app
Hi Amanda, Yes, Ken has made it available for download in the Google Play store for some Evergreen sites. The github branch was added to make it easier for other developers to get involved in working on/improving the app. Kathy On 09/06/2016 12:14 PM, Amanda Burroughs wrote: I assumed this app was ready to download. It seems to be working for my account. -Original Message- From: Open-ils-dev [mailto:open-ils-dev-boun...@list.georgialibraries.org] On Behalf Of Jason Stephenson Sent: Tuesday, September 06, 2016 10:49 AM To: Evergreen Development Discussion List Subject: Re: [OPEN-ILS-DEV] Android app Ken, This is great news! IF I can find the time, I might just see if I can get it to build with Android Studio and send pull requests your way. Cheers, Jason On 09/05/2016 06:38 PM, Ken Cox wrote: Jason Stephenson made the suggestion that to facilitate collaboration, I pull the Evergreen Android app out of the dark corner of the working repo and into the light. He even provided a filter-branches incantation to do it. Thank you, Jason. The code is now and for the indefinite future available at https://github.com/kenstir/hemlock/. I would now consider the sources in the Evergreen repo to be abandoned. In the README.md I have included a section "History of this app". If you notice inaccuracies or think someone else deserves a mention, let me know. Cheers, Ken --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] It is with deep regret and profound sadness...
Best wishes Justin and thank you for all of your contributions to the project! Kathy On 08/29/2016 01:39 PM, Galen Charlton wrote: Hi, On Mon, Aug 29, 2016 at 1:06 PM, Justin Hopkins 📖 mailto:jus...@mobiusconsortium.org>> wrote: Being a part of this community has been the most meaningful experience of my professional career. I've formed so many meaningful relationships in the Evergreen community and consider many of you to be my friends. Best of luck in the future! (And know that Evergreen is a community that is hard to entirely leave, and know that you are always welcome.) Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / Open Your Library email: g...@esilibrary.com <mailto:g...@esilibrary.com> direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Developers meeting
Hi all, The next developers meeting is scheduled for Wednesday, August 10 at 3 p.m. Eastern, 12 p.m. Pacific. A draft agenda has been posted to the wiki at http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2016-08-10 Feel free to add discussion items to the agenda. Have a nice weekend! Kathy On 08/04/2016 12:00 PM, Kathy Lussier wrote: Hi all, Looks like it's been a busy summer! Our last developers meeting was June 1, and with missed meeting dates in July and August, we don't have another one scheduled until September 7. I suggest that we try to schedule something for next week, especially since the 2.11 beta freeze is right around the corner. I've created a Doodle poll at http://doodle.com/poll/v9vdmicpgt3dgybd for scheduling the meeting. Thanks! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Developers meeting
Hi all, Looks like it's been a busy summer! Our last developers meeting was June 1, and with missed meeting dates in July and August, we don't have another one scheduled until September 7. I suggest that we try to schedule something for next week, especially since the 2.11 beta freeze is right around the corner. I've created a Doodle poll at http://doodle.com/poll/v9vdmicpgt3dgybd for scheduling the meeting. Thanks! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] holds not working in 2.7.3
Hi Gislaine, What is the error message that you receive? Kathy On 06/13/2016 11:01 AM, Hamelin, Gislaine (STATCAN) wrote: Hello List, Are any other libraries experiencing this problem? Since last Thursday, we have not been able to place holds. Not via the patron screens or in the catalogue. We see this error message and when we click on ‘Place Hold’ the submit button is greyed out. Many thanks! -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Thank you for a productive Bug Squashing Day!
Thank you Terran for all of your work to pull together yesterday's Bug Squashing Day. By all accounts, it looks like it was a big success! Kathy On 06/02/2016 06:47 PM, Terran McCanna wrote: Thank you to everyone who participated in today's Bug Squashing Day. Here is the current chart - if I've missed your name or some of your activity, please let me know. https://docs.google.com/spreadsheets/d/1zoqcCpuYxRAsrmdzpG3iO4sHRpsfBP2Z1_MMJhr6UfA/edit?usp=sharing I will check in the morning to add anything I've missed, then post the final statistics tomorrow. Terran McCanna PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, GA 30345 404-235-7138 tmcca...@georgialibraries.org <mailto:tmcca...@georgialibraries.org> -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Evergreen developers meeting next week
Hi all, We have an Evergreen developers meeting scheduled for Wednesday, June 1 at 3 p.m. Eastern, 12 p.m. Pacific. A draft agenda has been posted at http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2016-06-01. Feel free to add additional topics to the agenda. Have a nice weekend! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Hackfest Ideas Page
Hi all, During the last developer's meeting, I said I would throw this link out on to the list. I just realized that I never sent it along. We have a wiki page where people can add ideas for things you would like to discuss or work on during tomorrow's hackfest. Feel free to add your ideas here! http://wiki.evergreen-ils.org/doku.php?id=dev:hackfest:eg2016 Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Evergreen developer meeting today
Hi all, We have an Evergreen developer meeting scheduled today for 3 p.m. Eastern, 12 p.m. Pacific. The draft agenda is available at http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2016-03-06 Feel free to any discussions items to the agenda. Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Rescheduling developers meeting (was re: Change to feature slush/freeze)
Hi all, Actually, the 18th also has an EOB meeting, so we should probably scratch that date. After checking in IRC, it looks like the 17th works for folks. I've updated the dev calendar for the meeting to be scheduled at 3 p.m. (Eastern) Wednesday, February 17. Kathy On 02/10/2016 10:02 AM, Kathy Lussier wrote: Thanks Galen! I've updated the dates in the dev calendar. +1 to a new date for a developers meeting. It looks like we should avoid the 1 p.m. to 2:30 p.m. (eastern) time block on the 18th because there is an acq meeting scheduled at 1 p.m. Kathy On 02/10/2016 08:20 AM, Galen Charlton wrote: Hi, Unexpected personal matters have unavoidably consumed my available time the past few days, time that I would have used to prepare for feature slush. Consequently, I am changing the lead-up to release as follows: * 19 February 2015: feature slush * 26 February 2015: feature freeze - no non-bugfix patches to be pushed after this point * 2 March 2015: beta release * 10 March 2015: release candidate * 17 March 2015: 3.0.0 released I may not be able to attend the developers meeting tomorrow; I suggest that we consider rescheduling it to the 17th or 18th. Regards, Galen -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Change to feature slush/freeze
Thanks Galen! I've updated the dates in the dev calendar. +1 to a new date for a developers meeting. It looks like we should avoid the 1 p.m. to 2:30 p.m. (eastern) time block on the 18th because there is an acq meeting scheduled at 1 p.m. Kathy On 02/10/2016 08:20 AM, Galen Charlton wrote: Hi, Unexpected personal matters have unavoidably consumed my available time the past few days, time that I would have used to prepare for feature slush. Consequently, I am changing the lead-up to release as follows: * 19 February 2015: feature slush * 26 February 2015: feature freeze - no non-bugfix patches to be pushed after this point * 2 March 2015: beta release * 10 March 2015: release candidate * 17 March 2015: 3.0.0 released I may not be able to attend the developers meeting tomorrow; I suggest that we consider rescheduling it to the 17th or 18th. Regards, Galen -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Developer's meeting today
Hi all, It looks like we have a developers meeting scheduled today for 3 p.m. Eastern, 12 p.m. Pacific, 2000 UTC. I've created a page at http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2016-02-03 to collect agenda items. Thanks! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Fwd: Git Day at C/W MARS
Hi all, Re-sending this message to the list in case it got lost in you Inboxes over the holidays. Let us know if you would like to join us to learn about git! Kathy Forwarded Message Subject:[OPEN-ILS-DEV] Git Day at C/W MARS Date: Mon, 21 Dec 2015 17:12:38 -0500 From: Kathy Lussier Reply-To: Evergreen Development Discussion List Organization: Massachusetts Library Network Cooperative To: Evergreen Development Discussion List Hi all, During the Evergreen hack-a-way last month, we had a discussion about encouraging/mentoring volunteers to become more active in contributing to Evergreen. As a result, I was thinking it might be good to have a New England/Northeast area Evergreen contributors group that could meet regularly (every two or three months) to work on skills to become more active contributors. Think of it as a mini hack-a-way with a regional focus. To kick things off, I would like to invite other Evergreeners in the area to participate in a git day that we were originally planning to do solely among the MassLNC partners. The intended audience for this day are those who have the skills to contribute some code or documentation to Evergreen, but who need help getting up to speed with contributing them to the working repository with git. It will be an informal session, and will involve the following: I was planning to walk everyone through the process of pushing a code or documentation change to the Evergreen working repository. As such, I'm asking that people come prepared with a code or documentation change. Even if it's a custom code change you have on your server, it will be useful as an exercise to show you how it works. I find that you're more likely to understand how the process works if you actually push a change to the working repo, rather than watch somebody else doing it. I'll also walk people through the process of signing off on somebody else's code using git. Jason Stephenson from MVLC will also be on hand to talk to people about tracking local customizations using git. If anyone is interested in attending, the event will be held starting at 10 a.m. on Monday, January 25. The snow date is Monday, February 1. It will be held at C/W MARS headquarters in Worcester, MA and is open to any Evergreener who can make the drive to join us. If you're interested in coming, please send me a direct email to let me know. Thanks all! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Git Day at C/W MARS
Hi all, During the Evergreen hack-a-way last month, we had a discussion about encouraging/mentoring volunteers to become more active in contributing to Evergreen. As a result, I was thinking it might be good to have a New England/Northeast area Evergreen contributors group that could meet regularly (every two or three months) to work on skills to become more active contributors. Think of it as a mini hack-a-way with a regional focus. To kick things off, I would like to invite other Evergreeners in the area to participate in a git day that we were originally planning to do solely among the MassLNC partners. The intended audience for this day are those who have the skills to contribute some code or documentation to Evergreen, but who need help getting up to speed with contributing them to the working repository with git. It will be an informal session, and will involve the following: I was planning to walk everyone through the process of pushing a code or documentation change to the Evergreen working repository. As such, I'm asking that people come prepared with a code or documentation change. Even if it's a custom code change you have on your server, it will be useful as an exercise to show you how it works. I find that you're more likely to understand how the process works if you actually push a change to the working repo, rather than watch somebody else doing it. I'll also walk people through the process of signing off on somebody else's code using git. Jason Stephenson from MVLC will also be on hand to talk to people about tracking local customizations using git. If anyone is interested in attending, the event will be held starting at 10 a.m. on Monday, January 25. The snow date is Monday, February 1. It will be held at C/W MARS headquarters in Worcester, MA and is open to any Evergreener who can make the drive to join us. If you're interested in coming, please send me a direct email to let me know. Thanks all! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Reminder to add test plans to bug fixes
Hi all, As a result of discussion at the developers hackfest at the 2015 conference, we adopted a QA guideline to include a comment in git commit messages for bug fix patches that explains how to test the bug that the patch fixes. While preparing for next week's Bug Squashing Day, I spent some time this morning reviewing recent LP bug fixes. We have some bug fix patches that explain how to test the bug fix, but many others are still submitted without some kind of test plan. The rationale for including a test plan is it provides the tester with clear guidelines for ensuring that the patch does indeed do what the author intended. When I look at some of the bugs that have been languishing in Launchpad for months and, in some cases, even years, I often have the thought of "Looks great, but I have no idea how to test that." By incorporating an informal test plan in your commit messages and on the LP bug itself, you'll make it easier for testers to make the decision to test the patch and possibly increase the odds of the fix being merged to master. I just wanted to send along this reminder to please include these test plans in your git commit messages if your patch is fixing a bug. In some cases, it might not be a bad idea to include them in new feature branches too, especially if the new feature is particularly complicated or is covering an obscure test case that not all libraries are likely to encounter. If you are unsure of how the message should be written up, Galen provided an example on the QA page at http://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa. Thanks everyone! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Beta App Feedback
an option for search scope [-5]: Along the same lines, make user preferences already stored in Evergreen accessible/applicable (default locations, etc) or store new preferences for the app [-4]: Show some indication of consortium/system/branch levels in location dropdowns. It's not clear what is a system and what is a branch, and could make it too easy to set a system as the pickup location. I'm not sure how that would resolve. [-3]: Electronic resources don't display their 856 links [-2]: Subject and series information on the record pages could be links [-1]: A common feature among library apps, or apps where searching for books is a likely operation, is a barcode search - I think that would be a nice addition. Thanks again! I'm looking forward to playing around with this and putting it more to use. -- Regards, Justin -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Evergreen Test Writing Day
Hi all, Just to add some clarification on the dates, test-writing day is scheduled for today, November 17 and the point release is scheduled for tomorrow, November 18. I clarified the dates in IRC earlier when I realized there was confusion on the dates, but I neglected to send a follow-up email to the lists. Liam, I don't know how you want to proceed on re-scheduling or not, but I think it's fine to continue today. Kathy On 11/17/2015 12:30 PM, liam.wha...@bc.libraries.coop wrote: Because I scheduled the current Test Writing Day to take place on the same day as the Monthly Maintenance, I will postpone test writing day until next week. Here is a Doodle poll to help choose the new date: http://doodle.com/poll/6mbgkn22d29y25r3 I will add this new date to the Evergreen community calendar by the end of Friday this week. Liam Quoting Jason Stephenson : Quoting Kathy Lussier : Jason, do you think there will be much of a conflict with release day if we hold off on merging any of the tests until after tomorrow? The patches from the August test writing day weren't merged until last week, and, I don't see why it would be a problem waiting a few days to merge this batch. For monthly releases, I doubt that it would be a huge deal. I don't think the tests would normally get back ported to the release branches. I just recall that 2.9.0 release day was a bit of a pain because people kept pushing documentation commits after I had already started working on the release. I still think it would be a good idea to have test writing day or any other day involving code or documentation to fall on days other than release days. It is tough enough to get releases together without the added distractions. (Particularly difficult for me since our release schedule seems to fall on the day after my consortium's Executive and/or Membership meetings, so I have a day full of meeting the day before the release.) Cheers, Jason -- Jason Stephenson Assistant Director for Technology Services Merrimack Valley Library Consortium 4 High ST, Suite 175 North Andover, MA 01845 Phone: 978-557-5891 Email: jstephen...@mvlc.org -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Evergreen Test Writing Day
Hi all, I can grant access for the general community calendar as well as the developers calendar if anyone needs it. I think the test-writing days should probably be added to the dev calendar. Jason, do you think there will be much of a conflict with release day if we hold off on merging any of the tests until after tomorrow? The patches from the August test writing day weren't merged until last week, and, I don't see why it would be a problem waiting a few days to merge this batch. Kathy On 11/17/2015 08:53 AM, Jason Stephenson wrote: Hi, all! Tomorrow is also the monthly Evergreen patch release day. While I agree that test writing is very important, it may be better in the future to schedule it for a day other than the monthly patch releases. It would also be helpful if things like this could get added to the community calendar: http://evergreen-ils.org/communicate/calendar/ If you're organizing community events and don't have access to the appropriate calendar(s), then ask around. I forget exactly who can grant you access, but I'm sure there are more than one. Also, it very likely requires that you have a G+ account. Cheers, Jason -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] [RM] Call for roadmap entries for Evergreen 3.0
Hi all, As much as I try to avoid getting involved in release numbering discussions, I will say I agree with Chris, Jason, and Jim. I think the community should make a big PR splash when the full client is ready for production use, and the PR splash will be more meaningful with a big version jump at the same time. There have been a few moments in the 2.x series when we could have jumped to 3.0, particularly when template toolkit was ready for production. We've waited this long to make the jump, I think we can wait a little longer until the web client is fully ready. Having said that, I'm not going to beat a dead horse if the ultimate decision is to go to 3.0 Kathy On 11/09/2015 01:52 PM, James Keenan wrote: I agree with Chris and Jason. I also think, as Galen mentioned, 2.10 is an alright version number. Jim Jim Keenan Library Applications Supervisor jkee...@cwmars.org 508-755-3323 x23 C/W MARS 67 Millbrook St., Suite 201 Worcester, MA 01606 Save a tree! Please don't print this e-mail unless it's really necessary. Currently reading Swansong 1945 by Walter Kempowski. -Original Message- From: Open-ils-dev [mailto:open-ils-dev-boun...@list.georgialibraries.org] On Behalf Of Jason Stephenson Sent: Monday, November 09, 2015 9:43 AM To: Evergreen Development Discussion List Subject: Re: [OPEN-ILS-DEV] [RM] Call for roadmap entries for Evergreen 3.0 Quoting Chris Sharp : I think the criterion for a "3.0" release is pretty straightforward. If the web client will be fully usable in all major functionality (Circulation, Cataloging, Administration, Acquisitions), with multiple printer options and standalone in place and easily installable by a reasonably experienced Windows administrator, we should call it 3.0 and have a big splash news release about it. If not, I think we should go with 2.10. I agree that beating the dead horse of release numbering in general is not productive, but as with 2.0 several years ago, 3.0 should mean more than "that number was next". I just want to say that for the most part, I agree with Chris. I'm not married to version numbers, but I've long thought 3.0 should be reserved for when the browser staff client is recommended over the XUL client. -- Jason Stephenson Assistant Director for Technology Services Merrimack Valley Library Consortium 4 High ST, Suite 175 North Andover, MA 01845 Phone: 978-557-5891 Email: jstephen...@mvlc.org -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] Call for Release Manager Nominations
Hi all, I'm sending out a reminder that Release Manager nominations for the next Evergreen release are due by 11:59 PM EDT tomorrow, Friday, October 30. All nominations should be be sent to the open-ils-dev@list.georgialibraries.org list with a Cc: to the open-ils-gene...@list.georgialibraries.org list. Kathy On 10/13/2015 05:28 PM, Galen Charlton wrote: Hi, It is time to elect the Release Manager for the next Evergreen release. The Release Manager does not have to be a core committer, but does need to be familiar with Git and have contributed something to the Evergreen project whether it be code or documentation. Nominations (including self-nominations) are due by 11:59 PM EDT on Friday, October 30. Nominations should be made by email to open-ils-dev@list.georgialibraries.org with a Cc: to open-ils-gene...@list.georgialibraries.org. Replying to all on this email should also work. Nominees should send an email to both of the above mailing lists with some statements about their relationship to the Evergreen community and their goals for the next release. The elected release manager will be expected to adhere to the established schedule for the release milestones. The election will be held in the Evergreen IRC channel on freenode.net during the week of November 2. Later this week, I will circulate a poll for setting the specific date and time. Everyone is invited to participate in the voting. Evergreen core committers who cannot make the meeting may submit their vote via email to the open-ils-dev mailing list. BTW, it is perfectly OK to nominate yourself. Regards, Galen -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Evergreen search discussion
Hi all, I've added a topic to the hack-a-way agenda to discuss Evergreen search. However, I wanted to raise the topic here on the list first since the discussion may require some forethought and because I imagine there are people interested in this discussion who won't be attending the hack-a-way. In discussing our development priorities for the year, MassLNC decided to focus on making improvements to search in Evergreen. We view search as one of the most important pieces of the ILS, if not the most important. It's what allows our users to find those resources we spend so much time cataloging so that they can then place holds on them, check them out from the library, or access them in some other way. There are some specific development projects we identified as possibilities: Did you Mean? functionality, working auto-suggest, improved speed, etc. However, rather than tacking these improvements on to the existing search, we thought it might be a good time for the community to step back, take a big-picture look at how we're doing search, and determine if we should continue down this path, if we need to make major underlying changes for our current path to be more performant/effective, or if we should consider moving to something else to handle Evergreen search. Would it be worthwhile to move to something like Solr or Elasticsearch or something other thing to handle Evergreen searches? If not, are there changes we should do to better utilize improvements full-text search that have been made to recent versions of PostgreSQL? I don't have the answers to these questions, but I think it's worthwhile for the community to identify what we expect of Evergreen search and to do a thorough analysis of available options to determine what will best help us attain those goals. Over the past few months, the folks at MassLNC have started a discussion of what our overall goals for search are. From these discussions, we have created a vision for what we would like to see in Evergreen search - http://masslnc.org/search_vision . From this search vision, we then identified specific areas of improvements / new features that would help Evergreen reach this vision. We also identified areas where we already are doing well and will want to maintain - http://masslnc.org/node/3164. I'm sure there are some areas where others may disagree with our ideas, but I'm guessing there are other areas where we'll get broad community consensus around some of these search priorities. I don't think we're in a position where we can choose a direction at the hack-a-way, but maybe we can do the following: * At the hack-a-way, can we have a discussion to see if there is interest in this project? We might also be able to identify some viable options that could be explored at the hack-a-way. * After the hack-a-way, the community could work on setting and prioritizing high-level goals for search in the Evergreen catalog. Ideally, we would have these search goals ready by the end of the calendar year. I would be willing to help facilitate this process. * After the goals are identified, we explore available options to see which will the best to help us attain those goals. It would be great if we had the ability to do some prototypes during this phase, but this would depend on people having the time / resources to do those prototypes. * Ideally, by the time we meet again at the conference hackfest in April, we'll be in a position where we can set a direction for search and then move forward with development. I'm sure the process won't be as simple as what I outlined above, and all of you may have better ideas on the best ways to evaluate our options. But I'm hoping this email helps us kick off a conversation that ultimately leads to fast and relevant search in Evergreen. Thanks! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter:http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Keyboard shortcuts in the web client
Hi all, There is also an update on this issue. Galen filed https://bugs.launchpad.net/evergreen/+bug/1508477 this morning which indicates the issue I described should be fixed with an upgrade to the Angular hotkeys wrapper. Thanks Galen! Quoting Benjamin Kalish : You know, on second thought, I realize that there are two very different type of search interfaces in Evergreen: there are those where a search box exists on the page as a convenient but subservient part of the interface, and others where the search box is the primary means of interaction. I work so much with the first type, that I forgot that the second type, which is mostly used with a barcode scanner, will also appear in the web client. The second type should absolutely be autofocused—otherwise using the barcode scanner would be confusing and tedious. Benjamin Kalish Forbes Library / 413-587-1012 / bkal...@forbeslibrary.org Currently reading: *Our Mutual Friend* by Charles Dickens Just Finished: *Mind of the Raven: Investigations and Adventures With Wolf-birds by Bernd Heinrich.* On Tue, Oct 20, 2015 at 4:41 PM, McCanna, Terran < tmcca...@georgialibraries.org> wrote: I'm squarely in the pro-autofocus camp. The majority of our library staff rely almost exclusively on the keyboard and mouse. There are some people who use keyboard shortcuts frequently, but many more who never use any keyboard shortcuts at all. While I think it would be nice if the keyboard shortcuts are still available in the web client, I would be strongly opposed to the idea of removing the autofocus just for the sake of consistency. That would most definitely increase the number of clicks and reduce usability for our users. Terran McCanna PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, GA 30345 404-235-7138 tmcca...@georgialibraries.org - Original Message - From: "Benjamin Kalish" To: "Evergreen Development Discussion List" < open-ils-dev@list.georgialibraries.org> Sent: Tuesday, October 20, 2015 3:41:32 PM Subject: Re: [OPEN-ILS-DEV] Keyboard shortcuts in the web client My preference would be to have the focus never automatically focus on an input element, but instead have a keyboard shortcut to put the focus on the first/primary input element. This may be an extra keystroke on some pages, but it has the advantage that it can be consistent across all pages. An alternative, but to me less desirable, solution would be to include instructions in the documentation for how to use the tab key to move the focus away from an input element. The problem with this is that it works differently depending on the number and placement of input elements on the page. Benjamin Kalish Forbes Library / 413-587-1012 / bkal...@forbeslibrary.org Currently reading: *Our Mutual Friend* by Charles Dickens Just Finished: *Mind of the Raven: Investigations and Adventures With Wolf-birds by Bernd Heinrich.* On Tue, Oct 20, 2015 at 2:38 PM, Kathy Lussier wrote: > Hi all, > > I was going to send this question in response to Galen's RM proposal, but > I thought a separate thread will be better. > > I fully support Galen's proposal to get the web client ready for some > production use in the next release. However, there is one issue that I know > will be a barrier for adoption in our libraries and is something that I'm > not sure has an easy solution. > > Keyboard shortcuts are critical for the workflow of our circ desk staff. > At many circ desks, there isn't ample space to use a mouse, and switching > between the keyboard and mouse can be cumbersome. > > I know there are keyboard shortcuts available in the web client, but, last > I heard, there was a problem where they don't work if the cursor is already > focused on an input element in the client. Since we configure many of our > interfaces to immediately focus the cursor in an input element, this issue > is going to be problematic for front-line staff. > > This issue was discussed at a developers meeting a while ago, but nobody > came up with any ideas at that time. Has anyone come up with a solution > since then? If not, do you have a sense of whether this is a solvable > problem? > > Thanks! > Kathy > > -- > Kathy Lussier > Project Coordinator > Massachusetts Library Network Cooperative > (508) 343-0128 > kluss...@masslnc.org > Twitter: http://www.twitter.com/kmlussier > >
[OPEN-ILS-DEV] Keyboard shortcuts in the web client
Hi all, I was going to send this question in response to Galen's RM proposal, but I thought a separate thread will be better. I fully support Galen's proposal to get the web client ready for some production use in the next release. However, there is one issue that I know will be a barrier for adoption in our libraries and is something that I'm not sure has an easy solution. Keyboard shortcuts are critical for the workflow of our circ desk staff. At many circ desks, there isn't ample space to use a mouse, and switching between the keyboard and mouse can be cumbersome. I know there are keyboard shortcuts available in the web client, but, last I heard, there was a problem where they don't work if the cursor is already focused on an input element in the client. Since we configure many of our interfaces to immediately focus the cursor in an input element, this issue is going to be problematic for front-line staff. This issue was discussed at a developers meeting a while ago, but nobody came up with any ideas at that time. Has anyone come up with a solution since then? If not, do you have a sense of whether this is a solvable problem? Thanks! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Hack-A-Way Agenda
Hi all, With the hack-a-way less than a month away, the local planning team needs to get a good handle on numbers and travel arrangements to make sure we're prepared. If you're attending the hack-a-way, could you please help us out by doing the following?: * Add your name to the agenda at http://wiki.evergreen-ils.org/doku.php?id=hack-a-way-2015-agenda so that we can get an idea of how many people are attending. If your plans are still up in the air, it's fine if you just put a (maybe) next to your name. * If you need transportation to/from the airport, please add your travel times to the spreadsheet at https://docs.google.com/spreadsheets/d/1FsYv8wHww1eKrFUkn_Ur0s0w5-6waxZeWfTU3u6ay38/edit?usp=sharing * Please book your hotel rooms by tomorrow. The hotel will be releasing the room block after tomorrow. The group rate will still be available if there are rooms available, but we can't guarantee that rooms will be set after the 15th. Hotel info is available at http://wiki.evergreen-ils.org/doku.php?id=hack-a-way-2015 We look forward to seeing you all in Massachusetts next month! Kathy <http://wiki.evergreen-ils.org/doku.php?id=hack-a-way-2015-agenda> On 10/07/2015 03:20 PM, Rogan Hamby wrote: A shell is up for the agenda for the Hack-A-Way next month: http://wiki.evergreen-ils.org/doku.php?id=hack-a-way-2015-agenda Many thanks to kmlussier for noticing my oversights as I copied and pasted to make it. :) Feel free to list your participation and start adding to discussion topics, etc... -- Rogan Hamby, MLS, CCNP, MIA Managers Headquarters Library and Reference Services, York County Library System “You can never get a cup of tea large enough or a book long enough to suit me.” ― C.S. Lewis <http://www.goodreads.com/author/show/1069006.C_S_Lewis> -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Desperately Seeking Release Notes
Hi all, As the 2.9 beta deadline looks. I want to bring attention to several branches for new features that have the needsreleasenotes tag applied to them: https://bugs.launchpad.net/evergreen/+bugs?field.searchtext=&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.tag=needsreleasenote&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&search=Search&orderby=-id&start=0 If you are a developer and one of these bugs belongs to you, could you please add a release note entry for your new feature? Alternatively, if you are a DIG member who wants to help a developer out, writing a release notes entry on their behalf might help get that new feature ready for this week's release. Just be sure to make a comment on the Launchpad bug saying that you are writing the release note so that you don't duplicate each other's work. There are some tips for writing a release notes entry at http://wiki.evergreen-ils.org/doku.php?id=contributing:release_notes. There is also a template located in the docs/RELEASE_NOTES_NEXT directory that can get you started. I'm available in IRC if anyone has questions about how to write their release notes. Thanks! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] QA proposals
Hi Dan and Liam, Thanks for sharing your concerns regarding the time investment required to meet the QA requirements as proposed. I do understand that our developer resources in the community are low and time is at a premium, and I think we need to be aware of these constraints as we move forward with any QA requirements. I do want to point out that item 2 had a caveat at the end - "or by a statement from the patch author explaining that a test is infeasible without significant refactoring." Does the inclusion of this caveat help to address some of those concerns? Although the idea of a petition mechanism might work in larger communities, for our community, it leaves me with the question of who would have the time to then write that test is some kind of petition were made. I do want to respond to this comment from Dan: Ideally we might find some people willing to specialize in test writing, and perhaps someday our tests will be so comprehensive that many bug fixes won't need a totally new test, but neither outcome seems imminent at this time. During the January developers meeting, where we had the QA discussion that led to the new requirements, I posed the question of whether we needed to explore the idea of bringing on a person with an explicit commitment to review patches and write tests. The response I received to the idea was somewhat lukewarm, for reasons that I totally understand. However, if the developer community told me that they really needed somebody on board who specialized in test writing to be able to do the type of QA recommended in the Equinox report, I would do whatever I could to try to get the funding and expertise to make that happen. There were several Evergreen sites that felt strongly enough about QA to put funds into the Equinox QA study. I might be an optimist, but I believe we could get similar support in bringing this type of expertise on board. I would love to see the Calvin bug fixes in Launchpad sooner rather than later. If the time constraints on doing these tests is indeed too high for the developer time we have in the community, then we're left with a) lowering the bar for QA or b) doing what we can to grow the community so that we have somebody who can make the commitment to that work. I'm inclined to go with b) because I think it will lead to overall improvement for the software our libraries rely on. I'll also note that, at the same developers meeting, I volunteered to do an environmental scan of other projects to see how they handled these issues. It's something I have not done, other than some initial brainstorming with Galen, partially because I was waiting to see how things progressed with the new QA requirements and the test writing days. However, I'm willing to re-focus my energies there if people think it's useful. Kathy On 07/16/2015 03:02 PM, Dan Wells wrote: Hello all, I definitely support requiring tests for *new features*, but I do have some concerns that proposal [2] will have a dampening effect on getting bugs fixed. I understand the thinking that bug fixes sometimes cause more bugs, but I also think we also need to somehow incentivize bug fixes (being already unglamourous), and this policy makes it that much harder. I still don't directly oppose the policy, especially since I do not have any great ideas to address this. To make this more than abstract, we at Calvin have perhaps 10 or 20 smallish bug fixes in our local repository. It is a constant struggle to justify to our staff the time it is going to take me to get these into LaunchPad. If we're expected to also write tests, the timeline for getting these into LP probably just went from within 6 months to within 2 years, and maybe that is too generous. So, if we are adopting [2], I think we need to be careful to not marginalize or otherwise discourage sharing branches without tests, as that still gets us one step closer to where we need to be. Ideally we might find some people willing to specialize in test writing, and perhaps someday our tests will be so comprehensive that many bug fixes won't need a totally new test, but neither outcome seems imminent at this time. Sincerely, Dan From: Open-ils-dev on behalf of Galen Charlton Sent: Wednesday, July 15, 2015 12:25 PM To: Evergreen Development Discussion List Subject: Re: [OPEN-ILS-DEV] QA proposals Hi, On Wed, Jul 15, 2015 at 12:18 PM, Kathy Lussier wrote: Are these guidelines official now? As no objections were expressed... they are now. If so, I would like to update some wiki pages to reflect the new requirements: http://wiki.evergreen-ils.org/doku.php?id=contributing http://wiki.evergreen-ils.org/doku.php?id=dev:signoff_review_checklist Thanks! Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Sour
Re: [OPEN-ILS-DEV] QA proposals
Hi Galen et al., Are these guidelines official now? If so, I would like to update some wiki pages to reflect the new requirements: http://wiki.evergreen-ils.org/doku.php?id=contributing http://wiki.evergreen-ils.org/doku.php?id=dev:signoff_review_checklist If anyone knows of other pages that require updating, let me know. Kathy On 05/13/2015 05:03 PM, Galen Charlton wrote: Hi, A few concrete proposals for upping our QA game arose from the morning hackfest. Here they are for consideration: Guidelines for patch submission - [1] Any time a patch adds or alters a stored procedure, pgTAP tests that exercise its intended functionality should be included. [2] A change to database or Perl code that fixes a bug should be accompanied by a Perl (t or live_t) or pgTAP regression test – or by a statement from the patch author explaining that a test is infeasible without significant refactoring. [3] Bugfix patch commit messages should explain how to test the bug it fixes. For example: rather than just write a bare "LP#124565: fix Evergreen's cat-petting functionality", provide something more like: LP#124565: fix Evergreen's cat-petting functionality Evergreen does not do an adequate job of petting cats. To reproduce the problem: [1] Bring up an Evergreen OPAC and place a cat in front of it. [2] Observe that a hand appears and makes waving motions a centimeter over the cat. [3] Observe that the cat does not purr. [4] Apply the patch. [5] This time, verify that the hand actually makes contact with the cat. [6] Expected result: the cat purrs. To patch authors and testers: please provide feedback and +1/0/-1 on the three proposed new guidelines for patches. The first two essentially flesh out guidelines from <http://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa&s[]=pgtap>, while the third is meant to make it easier for folks to test complicated patches. There were two other proposals that folks have offered to work on: [A] Create a space for sharing manual test cases, such as the ones that MassLNC and PINES have already stockpiled. Champion: Kathy Lussier [B] Institute Test-writing Days, which would be scheduled events for folks to write automated tests, similar to the the focused Bug Squashing Days. Champion: Liam Whalen. Regards, Galen -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Revisiting web client catalog integration
I just realized I do have a Windows 8 laptop where I could test with
Firefox 37.0.2. I saw the same behavior there, with an added problem
where the last page didn't fully load. Screencast at
http://screencast.com/t/yxnvrlhYlr
Refreshing a catalog page is also problematic.
Kathy
On 04/23/2015 05:55 PM, Mike Rylander wrote:
Kathy,
Just to be clear, we're talking about the behaviour in Chrome
specifically, but not Firefox. Is that correct? Your browser controls
were obscured in the screencast, so I just wanted to confirm the
details. Firefox is doing the "right thing" for me.
All,
Here's a direct link to the context-providing wiki page that Kathy
link to through the markmail link below:
http://evergreen-ils.org/dokuwiki/doku.php?id=dev:browser_staff:dev_notes#section20140718
... That explains the background issues in a bit more technical detail.
As a side note, I know that the "double scrollbar" issue has been an
irritation to some. I've removed that for the embedded TPAC, which
was possible because it doesn't use onload handlers to render more
content. The Dojo interfaces will take some more work to handle, but
I think it may be possible to remove their scrollbars as well. That's
for later, though.
Thanks,
--
Mike Rylander
| President
| Equinox Software, Inc. / The Open Source Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: mi...@esilibrary.com <mailto:mi...@esilibrary.com>
| web: http://www.esilibrary.com
On Thu, Apr 23, 2015 at 3:27 PM, Kathy Lussier <mailto:kluss...@masslnc.org>> wrote:
Hi all,
After considerable testing of the web client and some follow-up
discussions with Equinox, I would like to revisit a discussion we
had last year regarding catalog integration in the web client -
http://markmail.org/message/zicsno2i7jlshpdb.
I think the use of iframes will be problematic for our users. When
testing, I've found that if I click to view holds for a bib
record, if I then click the browser's back button, I don't return
to the record. Instead, I go back to a different holds view and
then back to the advanced search screen. See the screencast at
https://drive.google.com/open?id=0B74gDMUDwDXqMXhBMlBmQUI3Uk0&authuser=0.
There are navigational elements in the UI to bring users back to
the record or to the search results. However, if there is a
browser back button, people will use it despite those navigational
elements. This is what makes the iframe issue distinct from what
we currently have available in the xul client. There is no
standard back button in the xul client, so people are forced to
use the other navigational elements available in the UI. We don't
have that level of control in the web client.
I am sending this e-mail to see if the collective wisdom of the
developer community may be able to come up with a solution that
will work well for our users. My preference is to not use iframes
at all, but my primary concern is getting the browser navigational
tools to work correctly.
Any thoughts?
Thanks!
Kathy
--
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org <mailto:kluss...@masslnc.org>
Twitter: http://www.twitter.com/kmlussier
--
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org
Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Revisiting web client catalog integration
Hi Mike,
Sorry, I meant to identify browsers. Yes, the screencast was in Chrome,
but I saw the exact same behavior in Firefox 37.0.1. I don't know if
it's relevant, but I am on a Linux computer. Looking at my notes, I
first noticed the problem back in the fall when I was still on a Windows
7 computer. It was occurring in both browsers at that time too.
I would be curious to hear if others are seeing the same issue in Firefox.
I am very happy to hear about the removal of the double scrollbar.
Keeping my fingers crossed that we can do the same for the Dojo interfaces!
Kathy
On 04/23/2015 05:55 PM, Mike Rylander wrote:
Kathy,
Just to be clear, we're talking about the behaviour in Chrome
specifically, but not Firefox. Is that correct? Your browser controls
were obscured in the screencast, so I just wanted to confirm the
details. Firefox is doing the "right thing" for me.
All,
Here's a direct link to the context-providing wiki page that Kathy
link to through the markmail link below:
http://evergreen-ils.org/dokuwiki/doku.php?id=dev:browser_staff:dev_notes#section20140718
... That explains the background issues in a bit more technical detail.
As a side note, I know that the "double scrollbar" issue has been an
irritation to some. I've removed that for the embedded TPAC, which
was possible because it doesn't use onload handlers to render more
content. The Dojo interfaces will take some more work to handle, but
I think it may be possible to remove their scrollbars as well. That's
for later, though.
Thanks,
--
Mike Rylander
| President
| Equinox Software, Inc. / The Open Source Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: mi...@esilibrary.com <mailto:mi...@esilibrary.com>
| web: http://www.esilibrary.com
On Thu, Apr 23, 2015 at 3:27 PM, Kathy Lussier <mailto:kluss...@masslnc.org>> wrote:
Hi all,
After considerable testing of the web client and some follow-up
discussions with Equinox, I would like to revisit a discussion we
had last year regarding catalog integration in the web client -
http://markmail.org/message/zicsno2i7jlshpdb.
I think the use of iframes will be problematic for our users. When
testing, I've found that if I click to view holds for a bib
record, if I then click the browser's back button, I don't return
to the record. Instead, I go back to a different holds view and
then back to the advanced search screen. See the screencast at
https://drive.google.com/open?id=0B74gDMUDwDXqMXhBMlBmQUI3Uk0&authuser=0.
There are navigational elements in the UI to bring users back to
the record or to the search results. However, if there is a
browser back button, people will use it despite those navigational
elements. This is what makes the iframe issue distinct from what
we currently have available in the xul client. There is no
standard back button in the xul client, so people are forced to
use the other navigational elements available in the UI. We don't
have that level of control in the web client.
I am sending this e-mail to see if the collective wisdom of the
developer community may be able to come up with a solution that
will work well for our users. My preference is to not use iframes
at all, but my primary concern is getting the browser navigational
tools to work correctly.
Any thoughts?
Thanks!
Kathy
--
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org <mailto:kluss...@masslnc.org>
Twitter: http://www.twitter.com/kmlussier
--
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org
Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Revisiting web client catalog integration
Hi all, After considerable testing of the web client and some follow-up discussions with Equinox, I would like to revisit a discussion we had last year regarding catalog integration in the web client - http://markmail.org/message/zicsno2i7jlshpdb. I think the use of iframes will be problematic for our users. When testing, I've found that if I click to view holds for a bib record, if I then click the browser's back button, I don't return to the record. Instead, I go back to a different holds view and then back to the advanced search screen. See the screencast at https://drive.google.com/open?id=0B74gDMUDwDXqMXhBMlBmQUI3Uk0&authuser=0. There are navigational elements in the UI to bring users back to the record or to the search results. However, if there is a browser back button, people will use it despite those navigational elements. This is what makes the iframe issue distinct from what we currently have available in the xul client. There is no standard back button in the xul client, so people are forced to use the other navigational elements available in the UI. We don't have that level of control in the web client. I am sending this e-mail to see if the collective wisdom of the developer community may be able to come up with a solution that will work well for our users. My preference is to not use iframes at all, but my primary concern is getting the browser navigational tools to work correctly. Any thoughts? Thanks! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Questions about security bugs/process
Thank you for your thoughts Dan. To be clear, I don't think people are being excluded as a punishment, and I understand perfectly that the intent is to decrease overall risk. I also want you to know I'm not trying to assign blame on the time it takes to fix security bugs. We are a small community with a lot of work on our hands. I'm also not advocating for broad alerts to the entire community regarding security problems. I guess what I'm really saying is that, if a trusted person from an Evergreen site wants to apply for access to the LP security bugs simply to gain "early access to information about security vulnerabilities in Evergreen," they should be allowed to do so. I'm guessing there would continue to be some "have-nots" out there because they never took the trouble to apply for access. But the option would be available to them if they wanted to use it. Second, by calling them “haves” and “have-nots”, this response seems to indicate that there is some intrinsic advantage to knowing about a security bug. I would argue that knowing about a bug and not being able to do anything about it is actually a burden. Oh, sure. Knowledge quite often is a burden for people, but I would argue that information that places a burden on people is quite often the information that is the most important for them to have, even if it causes some discomfort. I think I can highlight another area where we are assuming different things. We probably have different thoughts on what kinds of activity can lead to a solution. It's not just coding, testing, or helping to publicize the security release. It might be putting pressure on a support provider or on a developer community to get the problem fixed. It could be pressuring the EOB to finally gain some traction in setting up an emergency fund that could be used for security bugs. It could be the thing that galvanizes someone to get more involved in the community because they don't want to feel that burden anymore. I want more people to feel that burden. It shouldn't just be placed on the shoulders of our small developer community. Have a nice weekend everyone! Kathy On 03/13/2015 02:32 PM, Dan Wells wrote: Hello Kathy, I appreciate the concern expressed here, and struggled a lot with how to respond to the overall security problems. Perhaps it will help to highlight a few places where we are assuming different things. First, this response seems to assume that the average library will be able to mitigate security issues if they know about them. In some limited cases this might be true (e.g. don’t use credit card payments if the settings can be compromised), but the majority of bugs will not be simple to work around. It might make sense in some instances for the security team to put out a broad but nonspecific alert which says something like “a vulnerability exists in XYZ, please disable feature if possible until a fix is developed”, but even that must be weighed against inviting increased scrutiny and malicious intent. Second, by calling them “haves” and “have-nots”, this response seems to indicate that there is some intrinsic advantage to knowing about a security bug. I would argue that knowing about a bug and not being able to do anything about it is actually a burden. The goal of the security policy is to attempt to lower the overall risk to every interested party. It tries to include anyone the team is confident can and will help, and exclude everyone else, not as a punishment, but as the most viable and available means to actually **decrease** their overall risk. All that said, I do think we can try harder to err on the side of being more open, and the team is currently reevaluating some of the criteria for what kind of bug truly benefits from limited exposure and what does not. Sincerely, Dan Daniel Wells Library Programmer/Analyst Hekman Library, Calvin College 616.526.7133 *From:*Open-ils-dev [mailto:open-ils-dev-boun...@list.georgialibraries.org] *On Behalf Of *Kathy Lussier *Sent:* Friday, March 13, 2015 12:44 PM *To:* open-ils-dev@list.georgialibraries.org *Subject:* Re: [OPEN-ILS-DEV] Questions about security bugs/process Many thanks to the security team for considering the issues I raised in my e-mail and for opening up security team membership to a larger group of people. I certainly will be one of the people submitting my name for membership, and I hope people like Jeff Davis and Justin Hopkins, who have already shown interest in helping out, do the same. However, I do want to encourage the security team to think about going further with transparency. I'm specifically referring to this bit of the proposal: it is not to be treated simply as a means of gaining early access to information about security vulnerabilities in Evergreen. I totally understand why you want to restrict membership to
Re: [OPEN-ILS-DEV] Questions about security bugs/process
Many thanks to the security team for considering the issues I raised in my e-mail and for opening up security team membership to a larger group of people. I certainly will be one of the people submitting my name for membership, and I hope people like Jeff Davis and Justin Hopkins, who have already shown interest in helping out, do the same. However, I do want to encourage the security team to think about going further with transparency. I'm specifically referring to this bit of the proposal: it is not to be treated simply as a means of gaining early access to information about security vulnerabilities in Evergreen. I totally understand why you want to restrict membership to just those who commit to helping out with solutions. However, it is very important for sites running Evergreen to know about their system's vulnerabilities, even if they are not in a position to help with a solution. As an example, let me turn to an Evergreen feature that, as far as I know, doesn't have a security flaw, but does have a serious accessibility bug. If somebody sent out a message to the Evergreen list to ask about enabling auto-suggest, in addition to replying with information on how to configure it, I would also send along a strong word of caution given that the feature also makes your catalog totally inaccessible to users with screen readers - https://bugs.launchpad.net/evergreen/+bug/1187993. Some sites may decide to enable autosuggest anyway, but they are able to make that determination with all of the available information at hand. On the other hand, if I had been on the security team when the recently-fixed bug was still unresolved and somebody asked about setting up credit card processing, I wouldn't be able to give that person all of the information they needed to determine if it should be implemented. In fact, relaying that information, even if it were in confidence to an Evergreen user I trust not to exploit the bug or share the information, could result in my immediate expulsion from the team. This proposal will generally reduce the gaps between the haves and the have-nots (those who have information about security flaws and those who do not) in our community. However, it will still leave a lot of have-nots behind. I think large Evergreen sites, those that represent large consortia or big county library systems, are in the best position to have people who can contribute to security processes and, therefore, qualify for membership on the team. I suspect that what we will ultimately find is that larger Evergreen sites will be more likely to know about known security flaws while the small, single-library sites, will be more likely to be left out of the loop. In fact, I can't help but notice that the three non-security-team people who have participate in this discussion thus far are, indeed, representing large consortia. As a librarian, eliminating gaps between the haves and have-nots is very important to me, so this resolution does leave a bit of bad taste in my mouth. It could be that expanding the security team and re-focusing on processes will lead to more timely resolution of security bugs, in which case, my concerns about more widespread disclosure would be moot. However, I remain skeptical at this point. Thanks for listening! Kathy On 03/12/2015 04:53 PM, Galen Charlton wrote: Hi, On Wed, Mar 4, 2015 at 10:46 AM, Kathy Lussier <mailto:kluss...@masslnc.org>> wrote: > I really think we need to increase the transparency of these bugs > without compromising the security of our systems in the process. Any > site running Evergreen in a production environment should have a right > to know when a known security bugs affects their system, especially > when it comes to those bugs that have been left unresolved for many > months. Maybe we could allow one trusted person from each site > subscribe to security bugs or maybe there are other methods for > sharing this information for Evergreen sites. I would like to hear > thoughts from others on how we can improve transparency. One avenue towards improving the transparency of the security process is to ensure that there is a clear process for joining the security team. I am putting forward the following definition of the team and criteria for membership, and I am issuing a public call for interested people to join the security team: --- BEGIN --- The purpose of the Evergreen security team is to review reports of specific security flaws in Evergreen, to write and test patches to fix or ameliorate those flaws, and to perform security releases. Membership in the Evergreen security team is available to individuals who meet all of the following conditions: (1) They request membership. (2) They promise to adhere to the consensus of the security team regarding when to publicly disclose security issues. (3) They promise to maintain the confidenti
[OPEN-ILS-DEV] Questions about security bugs/process
Good morning Evergreen developers! Thanks to everyone for getting the recent security release out, particularly to Jason Stephenson for creating the fixes for the security issues and to Dan Wells, Ben Shum, and Bill Erickson for coordinating the release cutting. A couple of questions arose as I was reviewing the LP bugs that describe the problems that were being fixed by the security releases. LP1206589 was submitted on July 30, 2013 and is related to information that any site using credit card processing would want to keep private. We have one site that has been using credit card processing since before the bug was filed. I'm sure there are other sites in the community that were also using it or that may have decided to implement credit card processing after the bug was filed. All of these sites would have wanted to know that there was a security issue with these credit card settings, as well as the additional security issues identified in LP1424755. However, once LP1206589 was set to a private security bug in September 2013, these sites had no way of finding out that there was a security issue that a small group of community members were aware of. Knowledge of that security issue may have influenced their decision to implement/continue using credit card processing. If credit card processing was a critical service in their environments, they may also have made the decision to fund a fix for the bug sooner. Here are my questions regarding security bugs: Who is allowed access to security bugs and are there ways others in the community can find out about these bugs? I understand why we don't want this information available to the general public, but, IMO, the closed nature of security bugs only works in an environment where we know we can get a quick turnaround on fixes for critical security issues. What is the typical turnaround time for security bugs that are ultimately determined to be of critical or high importance? Was the turnaround time on this security issue unique or are there other security bugs that have been in LP for several months that would cause me to lose sleep if I knew they existed? I'm also curious about the general process that follows the submission of a security bug. Is there somebody that goes through them to identify which ones require some immediacy and then makes sure they get addressed in a timely manner? I really think we need to increase the transparency of these bugs without compromising the security of our systems in the process. Any site running Evergreen in a production environment should have a right to know when a known security bugs affects their system, especially when it comes to those bugs that have been left unresolved for many months. Maybe we could allow one trusted person from each site subscribe to security bugs or maybe there are other methods for sharing this information for Evergreen sites. I would like to hear thoughts from others on how we can improve transparency. Thanks! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] Questions about keyword search indexing
blob based on mods, they are experimenting with setting up all of their keyword indexes to be based on MARC tags. We've talked about two ways of making this happen: * Creating another keyword blob, similar to the current default index, that includes all of the MARC tags and subfields that we want included in the keyword index. Under this approach, we could easily add tags like the 260b or the 962 without creating an additional config.metabib_field entry. Those tags would just be incorporated in the main blob and, therefore, wouldn't be adding unintended weight to keyword searches or running up against the combined indexes problem. Under this scenario, there would still be cases where we would need to configure additional keyword indexes whenever we wanted to apply additional weight to a specific MARC field. * The other approach is to create multiple config.metabib_field entries for individual MARC tags, or perhaps for groups of tags. We would then turn the combined indexes on for keyword indexes. Based on Mike's comments at https://bugs.launchpad.net/evergreen/+bug/1169693/comments/2, since we no longer would have the large keyword blob, turning combined indexes on shouldn't lead to the relevance-ranking problems that arose when 2.4 was first released. We could then adjust the weight for those entries that include the more relevant MARC tags. However, I do have concerns that we'll continue to come across problems like the "Free Spirit" example I mentioned above where an exact match on a 260b tag will continue to float above other more relevant results. While this site continues looking at the indexes, can you tell me if there is anything we would be losing by going from indexes based on MODS to ones based purely on MARC tags? What were the original reasons for basing the default indexes on MODS? Also, are there any pros or cons to implementing either of the approaches I mentioned above? Do you see other ways to address some of the issues we've come across in creating custom indexes? Thanks in advance for your insight! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter:http://www.twitter.com/kmlussier #evergreen IRC: kmlussier
Re: [OPEN-ILS-DEV] Overdrive API integration
Hi Jeff, I can't respond to the specific downsides you mention in this e-mail, but I do think there is a lot of interest in seeing this Overdrive API support available in the next release of Evergreen if at all possible. Although it would be wonderful to have something that could be modified to work with other API's, I would rather see working code now than wait for the perfect solution if it's something that can be reasonably integrated into the core code. It seems like this would be a good topic for the " Feedback for New Features Under Development" portion of tomorrow's developer meeting. Will you be attending the meeting? Thanks for your work on this! Kathy On 01/12/2015 03:49 PM, Jeff Davis wrote: I mentioned a few months back that Sitka has been working on integrating Overdrive's API into the Evergreen OPAC -- specifically, using the Overdrive API to allow patrons to checkout and place holds (and view checkouts/holds, suspend or cancel holds, etc.) on Overdrive titles directly within the OPAC. Our code for this is currently in production for one of our libraries, and I'm expecting a couple more of our libraries to go live with it in the next few weeks. It's not fully documented yet, but the code is available here: http://git.sitka.bclibraries.ca/gitweb/?p=sitka/overdrive-evergreen-opac.git;a=summary Build and install instructions are outlined in the README. As currently implemented, this is a Javascript-based add-on or overlay to the existing OPAC. Actual changes to Evergreen are minimal: basically, we add a setting to config.tt2 which, if enabled, includes an overdrive.tt2 file which pulls in the OD API Javascript, as seen here: http://git.sitka.bclibraries.ca/gitweb/?p=sitka/evergreen.git;a=commitdiff;h=f8d5d13 One downside of this project in its current form is that it introduces new dependencies, particularly jQuery and require.js. It's also written in Coffeescript and requires a recent release of node.js to be compiled to Javascript (in my experience it will compile with the packaged version of node on Ubuntu 14.04, but not 12.04). Another downside is that it's closely tied to the Overdrive API specifically; it is perhaps possible to modify it to work with other APIs (e.g. OneclickDigital), but that's not as trivial as I'd have liked. It would obviously be great to have the Overdrive API integration available with the next release of Evergreen. Given the aforementioned downsides, though, I assume we don't want to include this in the 2.8 release as-is. On the other hand, it actually works. So I'm not quite sure how to proceed with integrating and supporting this project for the broader Evergreen community. -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Oct 2014 developer meeting
Can someone with access please add the date to the Evergreen calendar? done Thanks for meeting wrangling Bill! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier #evergreen IRC: kmlussier On 10/3/2014 2:32 PM, Bill Erickson wrote: Hi All, Monday, Oct 6th at 3pm Eastern is this month's winner. Agenda: http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-10-06 Can someone with access please add the date to the Evergreen calendar? Thanks, -b On Wed, Oct 1, 2014 at 10:38 AM, Bill Erickson <mailto:beric...@gmail.com>> wrote: Hi All, I've posted a Doodle poll for scheduling the next IRC developer meeting: http://doodle.com/5zautb9brzfknsxx Let us know when you're available to meet! -b
Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] Web Client (Sprint 1) demo - initial testing results
Mike, +1 to removing those options. I tend to agree, though I think it might be worth while for show-all to be possible for some UIs with just a few columns. Thoughts? Maybe in UI's that have 10 or fewer column picker options? Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier #evergreen IRC: kmlussier On 10/2/2014 2:05 PM, Mike Rylander wrote: On Thu, Oct 2, 2014 at 1:58 PM, Kathy Lussier <mailto:kluss...@masslnc.org>> wrote: Hi all, Sorry to be replying to an older thread, but I came across it while looking at column pickers in the web client. ITEMS OUT SCREEN - COLUMN PICKER: - I didn't go through every option, but there were obvious differences between the current staff client and the web client and definitely some columns missing that are in the current staff client. There are a few things missing (like checkout/checkin workstation and circ or renewal worktation), and the list of values in the web based client is not ordered alphabetically. We can fix the latter and the former is due to one of the known challenges going to a web interface. A longer and more explanatory email to come on that. Did we ever get the longer and more explanatory e-mail? I'm guessing it has something to do with cutting back our column picker options? I didn't go into a ton of detail, but I did respond, I'm pretty sure. However, I /did/ add the missing columns and add full-list sorting. Those commits are in a working branch that is waiting to be merged into master. - Show All Columns and Hide All Columns don't appear to do anything They surely don't. And honestly, I would not recommend anyone ever use "show all columns" - do we really need that option when we have 60+ column options? And, now that I think about it... Has anyone ever user hide all columns except after you accidentally chose show all columns? Any opinions on keeping those functions? +1 to removing those options. I tend to agree, though I think it might be worth while for show-all to be possible for some UIs with just a few columns. Thoughts? -- Mike Rylander | Director of Research and Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com <mailto:mi...@esilibrary.com> | web: http://www.esilibrary.com <http://www.esilibrary.com/> Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org <mailto:kluss...@masslnc.org> Twitter:http://www.twitter.com/kmlussier #evergreen IRC: kmlussier On 8/27/2014 9:13 AM, Grace Dunbar wrote: Answers inline. On Mon, Aug 25, 2014 at 6:32 PM, McCanna, Terran wrote: MAIN SCREEN OF INTERFACE: - Register Patron(s) link missing - Pull List for Hold Requests link missing - Catalog Search field missing - Advanced Search link missing - Item Status link missing To be clear, I assume you mean that all of the above should be added as "quick links" from the splash page? These actions - Register Patrons - Pull List for Hold Requests - Catalog Search - Advanced Search - Item Status are all available from the menus at the top. Since we're moving to a browser client and have the opportunity to re-think the splash page I think this might be a good time to get community input as to what actions should be included and how those should be organized. Should there even be a splash page with a browser client and, if so, what should be included as "quick links" by default? - Is the large Equinox banner across the bottom of the screen present because it's being hosted on an Equinox server, or is this something you have added to the default interface? Equinox would never brand the Evergreen open source product with its name. Never. This is simply a style banner to indicate that we are hosting this community test server. I'm sorry if that wasn't clear. MENUS: - Search Catalog link missing from Search dropdown menu We can add that. (Right now it appears under Cataloging, for those who are just following the email discussion) In the current client a link to search the catalog appears under both Cataloging and Search menus. Should we keep them both or eliminate one? PATRON FUNCTIONS: - When creating a new message on an account there is an empty dropdown box on the right side of the pop-up window - what is that for? I don't
Re: [OPEN-ILS-DEV] Web Client (Sprint 1) demo - initial testing results
Hi all, Sorry to be replying to an older thread, but I came across it while looking at column pickers in the web client. ITEMS OUT SCREEN - COLUMN PICKER: - I didn't go through every option, but there were obvious differences between the current staff client and the web client and definitely some columns missing that are in the current staff client. There are a few things missing (like checkout/checkin workstation and circ or renewal worktation), and the list of values in the web based client is not ordered alphabetically. We can fix the latter and the former is due to one of the known challenges going to a web interface. A longer and more explanatory email to come on that. Did we ever get the longer and more explanatory e-mail? I'm guessing it has something to do with cutting back our column picker options? - Show All Columns and Hide All Columns don't appear to do anything They surely don't. And honestly, I would not recommend anyone ever use "show all columns" - do we really need that option when we have 60+ column options? And, now that I think about it... Has anyone ever user hide all columns except after you accidentally chose show all columns? Any opinions on keeping those functions? +1 to removing those options. Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier #evergreen IRC: kmlussier On 8/27/2014 9:13 AM, Grace Dunbar wrote: Answers inline. On Mon, Aug 25, 2014 at 6:32 PM, McCanna, Terran wrote: MAIN SCREEN OF INTERFACE: - Register Patron(s) link missing - Pull List for Hold Requests link missing - Catalog Search field missing - Advanced Search link missing - Item Status link missing To be clear, I assume you mean that all of the above should be added as "quick links" from the splash page? These actions - Register Patrons - Pull List for Hold Requests - Catalog Search - Advanced Search - Item Status are all available from the menus at the top. Since we're moving to a browser client and have the opportunity to re-think the splash page I think this might be a good time to get community input as to what actions should be included and how those should be organized. Should there even be a splash page with a browser client and, if so, what should be included as "quick links" by default? - Is the large Equinox banner across the bottom of the screen present because it's being hosted on an Equinox server, or is this something you have added to the default interface? Equinox would never brand the Evergreen open source product with its name. Never. This is simply a style banner to indicate that we are hosting this community test server. I'm sorry if that wasn't clear. MENUS: - Search Catalog link missing from Search dropdown menu We can add that. (Right now it appears under Cataloging, for those who are just following the email discussion) In the current client a link to search the catalog appears under both Cataloging and Search menus. Should we keep them both or eliminate one? PATRON FUNCTIONS: - When creating a new message on an account there is an empty dropdown box on the right side of the pop-up window - what is that for? I don't seem to be able to do anything with it. What Bill said. It exists in the current client for custom penalties. We should probably put a label on it at the very least. - the Message pop-up window is missing the field to record staff initials that is in the current staff client Good catch. We'll add that. ITEMS OUT SCREEN - COLUMN PICKER: - I didn't go through every option, but there were obvious differences between the current staff client and the web client and definitely some columns missing that are in the current staff client. There are a few things missing (like checkout/checkin workstation and circ or renewal worktation), and the list of values in the web based client is not ordered alphabetically. We can fix the latter and the former is due to one of the known challenges going to a web interface. A longer and more explanatory email to come on that. - Show All Columns and Hide All Columns don't appear to do anything They surely don't. And honestly, I would not recommend anyone ever use "show all columns" - do we really need that option when we have 60+ column options? And, now that I think about it... Has anyone ever user hide all columns except after you accidentally chose show all columns? Any opinions on keeping those functions? - There is an optional column for "Due Date/Time" - what is that for? (It does not display the date and time from the normal "Due Date" column.) The labels come from a different place, sinc
Re: [OPEN-ILS-DEV] Introducing Dananji Liyanage
Hi Dananji, Welcome! Once you've had a chance to get familiar with Evergreen and have an idea of which project you are interested in, you might want to start with trying to fix one of our bitesize bugs or, if you decide to work on documentation, our bitesize documentation bugs. We have links to these bugs in the "Application requirement" section of our OPW page. http://wiki.evergreen-ils.org/doku.php?id=opw. Also note that if you are planning to submit an application for a coding project, then downloading and installing Evergreen should be one of the things you do as you get familiar with the software. Feel free to post questions here or in the #evergreen IRC channel if you come across any problems or have further questions! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier #evergreen IRC: kmlussier On 9/19/2014 1:56 AM, Dananji Liyanage wrote: Thanks a lot Yamil for the quick reply. I'm going through the Evergreen documentation and trying it out. I would like to work on either Documentation or Coding as long as I'm contributing to the community. What would you recommend as starter tasks to do when I get familiar with Evergreen? Thanks, Dananji Liyanage On Thu, Sep 18, 2014 at 9:33 PM, Yamil Suarez <mailto:ysua...@berklee.edu>> wrote: Hello, I am involved in the OPW project (Outreach Program for Women) for the Evergreen community. I am a mentor for the program, but only for the Evergreen Documentation project, but not for the coding or the UI Evergreen projects, etc. Do you know what project you might want to work with, because this will let us know which mentor(s) should respond to you to give you more help? I suspect that you have already seen the Evergreen wiki page dedicated to OPW http://wiki.evergreen-ils.org/doku.php?id=opw. I would recommend starting by going through some of the other tasks in the "Learning About Evergreen" section of http://wiki.evergreen-ils.org/doku.php?id=opw#learning_about_evergreen. Specifically, I would download the staff client from the community demo page and read through the existing documentation to learn a little about how Evergreen works. Let me know if this helps, Yamil On Thu, Sep 18, 2014 at 11:03 AM, Dananji Liyanage mailto:dan9...@gmail.com>> wrote: Hi all, I'm Dananji Liyanage, an Computer Science and Engineering undergraduate from University of Moratuwa Sri Lanka. I was going through the project list for the OutreachProgramForWomen and is very keen on contributing to the Evergreen project. I'm very interested in contributing but if someone can help me get started ( the to-do's for a newbie) that would be really helpful. -- Regards, Dananji Liyanage -- Yamil Suarez, MCS Library System Administrator/Developer Stan Getz Library Berklee College of Music 1140 Boylston St Boston, MA 02215 ysua...@berklee.edu <mailto:ysua...@berklee.edu> 617-747-2617
Re: [OPEN-ILS-DEV] Project ideas for Outreach Project for Women
Hi all, I just wanted to let everyone know that I added three potential coding projects to the OPW wiki page http://wiki.evergreen-ils.org/doku.php?id=opw. The first two came from discussions with a few other people: 1) Improvements to the self-check interface, including moving the interface to AngularJS and 2) a continuation of our responsive design work. The third, Awesome Box integration, was something I added today as I was remembering the great keynote we had at the last Evergreen conference. I think these projects should be doable for a developer new to Evergreen to accomplish in the time allotted (December 9 to March 9). However, I'm not a developer, so if anyone with more expertise thinks these are unreasonable, please let me know. There are two people who have volunteered to be mentors for the responsive design project, but we would need mentors for the other projects to include them on the final list. My preference is to have two co-mentors for a project to help minimize the per-mentor time commitment. If you are interested in mentoring either of these projects, feel free to add your name to the wiki. We need to let the OPW folks know our final decision by the end of the week, so I'm hoping volunteers can put their names forward by Friday morning. If there are other coding projects that you think might be good for this program, feel free to add them to the wiki. As far as criteria for what might make a good project, OPW made the following recommendations in the 'Defining a Project" section of the mentors page: The project should consist of manageable and relevant tasks that can be incorporated into the project throughout the internship period. Stand-alone projects proposed by an applicant are not suitable at all for people who are not established contributors. Please try to avoid situations when participants work on features that are not yet designed or agreed-upon, have too many moving parts, and would only land in the main code-base after the internship is over as a best-case scenario. This rarely works out. Instead, look for agreed-upon manageable bugs and small features that have a shared theme and would allow the participant to feel the satisfaction of landing her changes throughout the internship. Feel free to let me know if you have any questions! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier #evergreen IRC: kmlussier On 8/25/2014 12:49 AM, Kathy Lussier wrote: Hi all, Please excuse the cross-postings. At its meeting last week, the Executive Oversight Board discussed the possibility of participating in the GNOME Outreach Project for Women - http://gnome.org/opw/. The goal of OPW is to increase the participation of women in FOSS projects by connecting interns with communities that need help for specific projects. It is similar to the Google Summer of Code program in which Evergreen has previously participated, but the internships provided through this program can extend beyond coding. Interns could also work on user experience design, graphic design, documentation, web development, marketing, translation, or any other task that would help sustain the project. The EOB agreed to put forth the funds to cover the intern's stipend if, as a community, we could come up with some strong project ideas that will help the community and mentors willing to commit their time to the project I have started a page at http://wiki.evergreen-ils.org/doku.php?id=opw where we can start collecting potential project ideas. I had a couple of doc ideas that I have already added to the list. If you can think of anything that you think would be a worthwhile project, feel free to add it to the page. Please remember, though, that the projects need to be something that serve as an entry point for somebody who is entirely new to Evergreen. In talking about how to define a project, OPW suggests starting with smaller tasks (i.e. bugs) with a shared them and progressing over time to more complex tasks (i.e. features). They also ask that we select projects where the intern is likely to see their contributions incorporated in the project before the internship is over. Also, we need to make sure we have committed mentors on any project that is ultimately posted. The next OPW round starts September 8 when the names of participating organizations are released. The application deadline is October 22. During that application period, mentors may need to commit as much as 10 hours per week on the program since you'll be working with multiple potential applicants. I expect that it wouldn't be 10 hours per week for the entire application period, but that it will become more demanding as the application deadline approaches. The internship dates then run from December 9 to March 9, during which ti
Re: [OPEN-ILS-DEV] Web Client (Sprint 1) demo server
We've had some great discussion and feedback on the web client over the past few days. To help the developers track the issues with the web client, would it be better if we submit these issues via Launchpad as we do with other bug reports? Maybe we can use a webclient tag so that they are easily findable. Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier #evergreen IRC: kmlussier On 8/27/2014 1:00 PM, James Keenan wrote: Re: display of the patron edit screen. The frame that the patron edit screen is displayed in can cause the Save and Clone box to cover other buttons or parts of textboxes. Jim Jim Keenan Library Applications Supervisor jkee...@cwmars.org <mailto:jkee...@cwmars.org> 508-755-3323 x23 C/W MARS 67 Millbrook St., Suite 201 Worcester, MA 01606 *PSave a tree! Please don't print this e-mail unless it's really necessary.* Currently reading /Mistress Bradstreet /by Charlotte Gordon
[OPEN-ILS-DEV] Project ideas for Outreach Project for Women
Hi all, Please excuse the cross-postings. At its meeting last week, the Executive Oversight Board discussed the possibility of participating in the GNOME Outreach Project for Women - http://gnome.org/opw/. The goal of OPW is to increase the participation of women in FOSS projects by connecting interns with communities that need help for specific projects. It is similar to the Google Summer of Code program in which Evergreen has previously participated, but the internships provided through this program can extend beyond coding. Interns could also work on user experience design, graphic design, documentation, web development, marketing, translation, or any other task that would help sustain the project. The EOB agreed to put forth the funds to cover the intern's stipend if, as a community, we could come up with some strong project ideas that will help the community and mentors willing to commit their time to the project I have started a page at http://wiki.evergreen-ils.org/doku.php?id=opw where we can start collecting potential project ideas. I had a couple of doc ideas that I have already added to the list. If you can think of anything that you think would be a worthwhile project, feel free to add it to the page. Please remember, though, that the projects need to be something that serve as an entry point for somebody who is entirely new to Evergreen. In talking about how to define a project, OPW suggests starting with smaller tasks (i.e. bugs) with a shared them and progressing over time to more complex tasks (i.e. features). They also ask that we select projects where the intern is likely to see their contributions incorporated in the project before the internship is over. Also, we need to make sure we have committed mentors on any project that is ultimately posted. The next OPW round starts September 8 when the names of participating organizations are released. The application deadline is October 22. During that application period, mentors may need to commit as much as 10 hours per week on the program since you'll be working with multiple potential applicants. I expect that it wouldn't be 10 hours per week for the entire application period, but that it will become more demanding as the application deadline approaches. The internship dates then run from December 9 to March 9, during which time you may need to spend up to five hours per week working with the intern. Due to the time commitment, I think we should shoot for two mentors on each project so that the commitment does not fall on just one person. There is more information for potential mentors at https://wiki.gnome.org/OutreachProgramForWomen/Admin/InfoForMentors. We need to let OPW know by September 8 if we plan on participating, so we have about two weeks to see if we can pull together some strong projects. However, I think this is doable if we have some willing volunteers and good project ideas. Feel free to let me know if you have any questions! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] Bug squashing days
Hi all, Let's go with Tuesday, August 26. I'll send out more details as we get closer. Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 8/6/2014 12:05 PM, Kathy Lussier wrote: Hi all, I'm sending out a last call to fill out the Doodle poll for Bug Squashing Day at http://doodle.com/2dx9h3cccwbp84v4. I plan to close the poll at the end of the day tomorrow. As of now, it looks like Monday, August 25 to Wednesday, August 27 are the best dates. Thanks! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 8/1/2014 11:08 AM, Kathy Lussier wrote: Hi all, Unfortunately, it looks like I mistakenly added July dates to the poll instead of some of the August dates we were polling. I usually can edit a Doodle poll to fix these mistakes, but Doodle just isn't cooperating with me on this poll. Therefore, I had to create a new poll for bug squashing day. The poll is available at http://doodle.com/2dx9h3cccwbp84v4. Anyone who filled out the first poll will need to enter their dates again on the new poll. Sorry! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 7/29/2014 1:45 PM, Kathy Lussier wrote: Hi all, Based on the discussion at yesterday's developers meeting, I'm putting out a poll to find out when people would be available for the Bug Squashing Day. To give us plenty of time to get ready, I'm targeting the final two weeks of August, but I have excluded days when we have previously-scheduled Evergreen meetings (EOB and web team.) The poll is available at http://doodle.com/6ush6hyx9pa39pv3. Once again, this day is not just for developers. We're looking at setting up sandboxes to make it easier for people to make it easier to test bug fixes. If you think you might be interested in testing patches or in helping to confirm bugs, please take time to fill out the Doodle poll. Thanks all! I think it will be a great day and, hopefully, a productive one as well! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 7/25/2014 7:27 PM, Kathy Lussier wrote: Hi all, Last fall, I put out an e-mail message suggesting community bug squashing days- http://markmail.org/message/22six3nkgbhr3f3t. It received some support at the time, but I didn't do any follow-through to make it happen. Last week, I took some time to update a local spreadsheet I'm maintaining on Launchpad bugs that are important to libraries in the three MassLNC networks. I was pleased to remove some bugs that have since been fixed, but then I added a whole lot more. We started with about 50 bugs on the list, and the number is now at 83. These numbers reminded me of how it important it is that we try to allocate some time on a community level to fix bugs. I have a more formal proposal I would like to put forward and, if it's agreeable to others, I commit to doing my part to try to make these days happen. Proposal: Evergreen Bug Squashing Days Goal: The goal of bug squashing days is for contributors and volunteers to commit the entire day to the following activities: * Fixing bugs * Testing bugs that have pullrequests * General bug wrangling activities (confirming bugs, marking duplicates, etc.) * Pushing bug fixes into Evergreen (for core committers) When: I'm proposing that we try to schedule bug squashing days on a quarterly basis. I was thinking August/November/February/May would be a good schedule where the bug squashing days aren't running up against an Evergreen release. What is Needed: * Somebody to work on scheduling the day and set up a wiki page (I volunteer, but am happy to hand off the task or work with somebody else if needed.) * Volunteers willing to devote a day of their time to the above activities. These volunteers do not need to just be developers or sys admins. Anyone can confirm bugs, look for duplicates, or perhaps team up with a sys admin to test patches. Extras: The idea for these bug squashing days came from similar days organized by the Koha community. http://wiki.koha-community.org/wiki/Category:Global_bug_squashing_days. They do a couple of things that I would love to see for Evergreen bug squashing days. * The Koha community uses this great scoreboard on bug squashing days - http://scoreboard.koha-community.org/. The code for the scoreboard is available at https://gitorious.org/scoreboard/scoreboard. It would be great if we had a volunteer who was willing to create a similar scoreboard for Evergreen bug squashing days. * The Koha community
Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] Bug squashing days
Hi all, I'm sending out a last call to fill out the Doodle poll for Bug Squashing Day at http://doodle.com/2dx9h3cccwbp84v4. I plan to close the poll at the end of the day tomorrow. As of now, it looks like Monday, August 25 to Wednesday, August 27 are the best dates. Thanks! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 8/1/2014 11:08 AM, Kathy Lussier wrote: Hi all, Unfortunately, it looks like I mistakenly added July dates to the poll instead of some of the August dates we were polling. I usually can edit a Doodle poll to fix these mistakes, but Doodle just isn't cooperating with me on this poll. Therefore, I had to create a new poll for bug squashing day. The poll is available at http://doodle.com/2dx9h3cccwbp84v4. Anyone who filled out the first poll will need to enter their dates again on the new poll. Sorry! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 7/29/2014 1:45 PM, Kathy Lussier wrote: Hi all, Based on the discussion at yesterday's developers meeting, I'm putting out a poll to find out when people would be available for the Bug Squashing Day. To give us plenty of time to get ready, I'm targeting the final two weeks of August, but I have excluded days when we have previously-scheduled Evergreen meetings (EOB and web team.) The poll is available at http://doodle.com/6ush6hyx9pa39pv3. Once again, this day is not just for developers. We're looking at setting up sandboxes to make it easier for people to make it easier to test bug fixes. If you think you might be interested in testing patches or in helping to confirm bugs, please take time to fill out the Doodle poll. Thanks all! I think it will be a great day and, hopefully, a productive one as well! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 7/25/2014 7:27 PM, Kathy Lussier wrote: Hi all, Last fall, I put out an e-mail message suggesting community bug squashing days- http://markmail.org/message/22six3nkgbhr3f3t. It received some support at the time, but I didn't do any follow-through to make it happen. Last week, I took some time to update a local spreadsheet I'm maintaining on Launchpad bugs that are important to libraries in the three MassLNC networks. I was pleased to remove some bugs that have since been fixed, but then I added a whole lot more. We started with about 50 bugs on the list, and the number is now at 83. These numbers reminded me of how it important it is that we try to allocate some time on a community level to fix bugs. I have a more formal proposal I would like to put forward and, if it's agreeable to others, I commit to doing my part to try to make these days happen. Proposal: Evergreen Bug Squashing Days Goal: The goal of bug squashing days is for contributors and volunteers to commit the entire day to the following activities: * Fixing bugs * Testing bugs that have pullrequests * General bug wrangling activities (confirming bugs, marking duplicates, etc.) * Pushing bug fixes into Evergreen (for core committers) When: I'm proposing that we try to schedule bug squashing days on a quarterly basis. I was thinking August/November/February/May would be a good schedule where the bug squashing days aren't running up against an Evergreen release. What is Needed: * Somebody to work on scheduling the day and set up a wiki page (I volunteer, but am happy to hand off the task or work with somebody else if needed.) * Volunteers willing to devote a day of their time to the above activities. These volunteers do not need to just be developers or sys admins. Anyone can confirm bugs, look for duplicates, or perhaps team up with a sys admin to test patches. Extras: The idea for these bug squashing days came from similar days organized by the Koha community. http://wiki.koha-community.org/wiki/Category:Global_bug_squashing_days. They do a couple of things that I would love to see for Evergreen bug squashing days. * The Koha community uses this great scoreboard on bug squashing days - http://scoreboard.koha-community.org/. The code for the scoreboard is available at https://gitorious.org/scoreboard/scoreboard. It would be great if we had a volunteer who was willing to create a similar scoreboard for Evergreen bug squashing days. * The Koha community also has Sandboxes available that makes it easier for librarians to test patches. It may be a little difficult to pull together something for Evergreen that's as automated as these Sandboxes, but I think it's worthwhile to set a goal to eventually have some Sandbox servers available to the
[OPEN-ILS-DEV] Sandboxes for Bug Squashing Days
Hi all, Following up on the bug squashing day discussion from yesterday's dev meeting, I'm following up on my action item to continue discussion of test sandboxes for the Bug Squashing Day. During the meeting, MOBIUS volunteered a test server to be used as a Sandbox (thank you Justin!). The Koha community has Sandboxes available for use by the community, and Galen described them as being fairly automated. A user specifies a bug number in the interface, and, a few minutes later, an Evergreen instance is running with the patch applied. We were discussing the need to probably do a more manual process for Evergreen sandboxes. Testers would need to volunteer to test patches ahead of time to give people time to set up the Sandboxes. However, after the meeting, I talked with Jason Stephenson and Thomas Berezansky at MVLC about the possibility of using a MassLNC server for 2 to 3 VM's that could be used as sandboxes on bug squashing day. They also have ideas for making the process automated, similar to the sandboxes that are used in the Koha community, and would be able to share code with MOBIUS and anyone else who might want to volunteer a server. If they're successful, then I don't think it's as critical for people to claim bugs ahead of time. We can report back when Jason and Thomas have made more progress. I think the availability of Sandboxes raises some other questions. If the idea is for the Sandboxes is to make it easier for more people to test patches, do we also expect those people to do git signoffs too. If so, I think it might be a good idea to have some screencasts showing people how to do a git signoff with something like Git GUI, but I also wanted to raise the question of whether it is necessary or if we might want to accept LP bug comments as a sign off? Are there other potential issues people see with the use of these Sandboxes? Thanks! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] July 2014 developers meeting
Hi all, The July developers meeting will be held on Monday, July 28 at 3 p.m. Eastern, 12 p.m. Pacific, 19:00 UTC. Feel free to add items to the draft agenda at http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-07-28. Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 7/18/2014 2:14 PM, Kathy Lussier wrote: Hi all, It's time to schedule the July developers meeting. I've posted a Doodle poll at http://doodle.com/2iqbmun3f7daeedg. Let us know when you're available to meet! Kathy
[OPEN-ILS-DEV] July 2014 developers meeting
Hi all, It's time to schedule the July developers meeting. I've posted a Doodle poll at http://doodle.com/2iqbmun3f7daeedg. Let us know when you're available to meet! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] URI scoping in Evergreen
Hi Mike and Liam, Here is what I was trying to communicate. Aside from cases where we explicitly do not want URIs being displayed, the records should be scoped according to the fenced of area of the URI. So, if the Search OU or Pref OU falls within the fencing, then the record should be returned in the search results. However, copies still need to be considered because a record might have a copy owned by one library which does not have a 856 $9, and it might also have a library with an 856$9. In that case, the record needs to be displayed in the search results for the first library in the manner that copy visibility currently works. In the second case the record needs to be displayed in the manner we are currently discussing. I believe the luri_act_as_copy flag currently removes records with copies but not 856 $9 from the results when there are non-relevant (to the search or pref OU) 856 $9 values within the record. luri_act_as_copy absolutely should /not/ be removing records with visible copies but no visible 856$9. If that is happening, it is a bug and I would be very interested in seeing an example so I can squash it. For non-deleted records, visibility testing is designed to be inclusive, not exclusive, so if anything causes a record to be included in the result set (visible copy, visible LURI, transcendent, completely empty (for staff)) then it is included -- period. I just tested this on a master system and it worked as expected. With the luri_act_as_copy flag enabled, I was able to find this record - http://jasondev.mvlcstaff.org/eg/opac/record/1559434 - when I was scoped to the library that had a copy record and when I was scoped to the library identified in subfield 9.
[OPEN-ILS-DEV] Fwd: Re: Details about DCO
Hi all, Depesz sent this e-mail to the dev list yesterday, but it looks like it didn't go through. I'm forwarding along and will add a link to it on the two LP bugs noted below. Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier Original Message Subject:Re: Details about DCO Date: Tue, 1 Jul 2014 16:19:29 +0200 From: hubert depesz lubaczewski Reply-To: dep...@depesz.com To: Kathy Lussier On Tue, Jul 01, 2014 at 09:55:37AM -0400, Kathy Lussier wrote: Hi Depesz, Could you send the e-mail to the Evergreen dev list? open-ils-dev@list.georgialibraries.org <mailto:open-ils-dev@list.georgialibraries.org> I just did (copy of email text below) - not sure if it will get posted, though, as I'm not subscriber of the list (can subscribe if necessary). Best regards, depesz Copy of mail text: Hi, I tried to register on launchpad, but it fails, so after suggestion from Kathy Lussier, I'm sending it in here. This is related to: https://bugs.launchpad.net/evergreen/+bug/1234845 and https://bugs.launchpad.net/evergreen/+bug/1236979 (text taken from https://bugs.launchpad.net/evergreen/+bug/578586/comments/2, as I can't open wiki.evergreen-ils.org/doku.php?id=dev:standing_dco now) Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. Signed-off-by: Hubert depesz Lubaczewski Best regards, depesz -- The best thing about modern society is how easy it is to avoid contact with it. http://depesz.com/ signature.asc Description: PGP signature
Re: [OPEN-ILS-DEV] Question about documentation for open-ils.ingest
Thank you Galen! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 6/30/2014 11:43 AM, Galen Charlton wrote: Hi, On Fri, Jun 27, 2014 at 1:31 PM, Kathy Lussier wrote: The page is a list of OpenSRF services available as of 1.6. It's easy enough for me to remove the reference to open-ils.ingest service from the list, but I'm wondering if there are other additions/removals I should be making from that list. Have there been other changes to the services since 1.6? Or is this a task that is bigger than just updating the list of OpenSRF services? Here's the list of services available in 2.6, along with additional descriptions. open-ils.acq Supports tasks for managing the acquisitions process open-ils.actor open-ils.auth open-ils.auth_proxy Support using external services such as LDAP directories to authenticate Evergreen users open-ils.booking Supports tasks for media booking open-ils.cat open-ils.circ open-ils.collection open-ils.cstore open-ils.fielder open-ils.justintime Support tasks for determining if an action/trigger event is still valid open-ils.pcrud Supports access to Evergreen fieldmapper objects, restricted by staff user permissions. This is a private service. open-ils.penalty open-ils.permacrud Supports access to Evergreen fieldmapper objects, restricted by staff user permissions. This is a private service. open-ils.reporter open-ils.reporter-store open-ils.resolver Support tasks for integrating with an OpenURL resolver open-ils.search open-ils.serial Support tasks for serials management open-ils.storage open-ils.supercat open-ils.trigger open-ils.url_verify Support tasks for validating URLs open-ils.vandelay opensrf.settings Supports communicating opensrf.xml settings to other services. Regards, Galen
[OPEN-ILS-DEV] Question about documentation for open-ils.ingest
Hi all, I'm hoping one of you can help me with this question I have regarding the removal of the open-ils.ingest service. DIG is working very hard to get the changes from 2.6 incorporated into the official documentation by next week. As you know, one of those changes is the removal of the open-ils.ingest service. The Release Notes seem to do a good job of documenting the fact that Evergreen sites need to remove some data from the opensrf.xml file. I don't think this type of information is required elsewhere in the official docs since it's something need to know the one time they upgrade beyond 2.5. However, I do want to make sure references to open-ils.ingest are removed from other pieces of the documentation. There is only one place in the official documentation where I see a reference to the open-ils.ingest service - in the Easing gently into OpenSRF chapter - http://docs.evergreen-ils.org/2.6/_evergreen_specific_opensrf_services.html. The page is a list of OpenSRF services available as of 1.6. It's easy enough for me to remove the reference to open-ils.ingest service from the list, but I'm wondering if there are other additions/removals I should be making from that list. Have there been other changes to the services since 1.6? Or is this a task that is bigger than just updating the list of OpenSRF services? Thanks in advance for your help! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
[OPEN-ILS-DEV] June developers meeting
It's that time again! Please fill out the Doodle poll at http://doodle.com/bqwp3e334zpa33f8 to let us know when you'll be available for the June Evergreen Developers meeting. Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] May developers meeting
Hi all, It looks like 2 p.m Eastern, 11 a.m. Pacific, 18:00 UTC on Monday, May 19 works for most people. Let's plan on meeting then. A draft agenda has been started at http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-05-19. Feel free to add your agenda items to the wiki. Thanks all! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter:http://www.twitter.com/kmlussier On 5/6/2014 5:11 PM, Kathy Lussier wrote: Hi all, It's time to schedule the May developers meeting. Let's try to schedule something during the week of May 19. I have set up a Doodle poll at https://doodle.com/ncdke3xitdzvwfwa. Thanks! Kathy
[OPEN-ILS-DEV] May developers meeting
Hi all, It's time to schedule the May developers meeting. Let's try to schedule something during the week of May 19. I have set up a Doodle poll at https://doodle.com/ncdke3xitdzvwfwa. Thanks! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Evergreen 2014 conference presentations posted online
Hi Glenn, The Evergreen web site appears to be down at the moment. It just happened to coincide with Yamil sending his e-mail message. Perhaps it was all those people anxious to look at the presentations. ;) Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 4/22/2014 1:28 PM, BUNTON, GLENN wrote: Never a good sign when a technology list has a url that doesn't appear to work. Tried in various browsers and it just spins. -Original Message- From: open-ils-dev-boun...@list.georgialibraries.org [mailto:open-ils-dev-boun...@list.georgialibraries.org] On Behalf Of Yamil Suarez Sent: Tuesday, April 22, 2014 1:16 PM To: General Evergreen List; Documentation discussion for Evergreen software; Evergreen Community Catalogers; Development Evergreen list Subject: [OPEN-ILS-DEV] Evergreen 2014 conference presentations posted online Hello, My apologies for the cross-posting to all the Evergreen mailing lists. I just wanted to alert the community that all the conference presentations have been posted on the conference schedule page. http://evergreen-ils.org/conference/eg14/schedule/ The only exceptions are the David Weinberger presentation and some of the lightning talk presentations. We currently are reaching out to Mr. Weinberger to get a copy, and if you gave a lightning talk presentation let me know if you want us to post something for you. Also, please let me know if I made a mistake with the presentation linking so I can correct it. Thanks, Yamil Yamil Suarez, MCS Library System Administrator/Developer Stan Getz Library Berklee College of Music 1140 Boylston St Boston, MA 02215 ysua...@berklee.edu 617-747-2617
Re: [OPEN-ILS-DEV] April developers meeting
Hi all, Let's plan to meet Tuesday at 2 p.m. Eastern, 11 a.m. Pacific, 18:00 UTC The draft agenda is available at http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-04-08. Feel free to add any business items to the agenda. One note about this month's agenda. Based on our soon-to-be 2.next Release Manager's recent e-mail to the community - http://markmail.org/message/b23u62e6rhebjkhk - I have added a standing agenda item called "Feedback for New Features Under Development." I'll just quote from Ben's e-mail on what might be covered under this agenda item: This is intended to give more direct feedback for new development which may impact large areas of Evergreen and bring it to the attention of the whole group. It continues to be a strong recommendation for any developer to announce new development work early via Launchpad, lists, etc. for greater community review and feedback. The topic will be included on the agenda every month so that anyone who has pending projects meeting this definition can add that project to this section of the agenda. I have also removed GSoC updates from the standing agenda since we do not have any GSoC projects this year. We also need a volunteer to run next week's meeting. Thanks all! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 4/1/2014 4:41 PM, Kathy Lussier wrote: Hi all, It's time to schedule the monthly Evergreen developers meeting. The meeting poll is available at http://doodle.com/ze47agcsia9mdhdb. Let us know when you're available! Kathy
Re: [OPEN-ILS-DEV] [OPEN-ILS-GENERAL] Smart Float: Self balancing floating collections
Hi Doug, Thanks for sharing your plans. I don't think we have a lot of libraries using floating collections in Mass., but it looks like this feature would add some nice flexibility if we saw more libraries making use of floating collections. All of this functionality looks fantastic! I do have one question/comment. You mention that you are running the code in 2.2. In 2.5, Evergreen added floating groups that allow sites to identify where floating items are allowed to float. For example, a multi-branch library in our consortium might want to float things among its branches, but not among all the libraries in the entire consortium. I'm must wondering if your code would play nicely with the floating groups code so that a system that is floating items among its branches can also take advantage of these features. Thanks! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 4/2/2014 11:51 AM, Doug Kyle wrote: I've created a new Evergreen feature I call Smart Float. After we (Grand Rapids Public Library) moved to floating collections, staff had to spend time managing and balancing floating collections. Smart Float was created to automate those tasks as follows. Smart Float automates the redistribution of floating collections based on available shelf space and duplicate copies. Smart Float also allows automatic "re-homing" of items based on a number of circulations from the original library or a specified time frame. Upon checkin Smart Float will first check if an item needs to be sent home, if not the item will float to the checkin branch if space is available and there are not too many duplicate copies. If space and or duplicates don't allow floating to the checkin branch, it will next float to the branch with most space and no excess duplicates, then to the branch with most space regardless of duplicates. If no branches have shelf space it will stay where it is (float to the checkin library). Copy locations are the units of Smart Float operation. Copy locations are mapped to the following attributes that Smart Float uses to determine how to distribute copies. - active: if true, Smart Float will be used, otherwise traditional floating will occur. - items_allowed: the number of items the shelving location can hold. - dups_threshold: the number of duplicate titles allowed for that copy location. - homing_threshold: number of circulations from the original owning library. - homing_lifespan: time interval, such as "3 months". Items will be sent home within the homing_lifespan from creation date, until the homing_threshold is met. So if shelving location 'kids movies' has a homing_threshold of 1 and a homing_lifespan of "3 months", items in that shelving location won't start floating until they have circulated once from the owning library, or its been 3 months or more since they were created. The Grand Rapids Public Library is now running an initial version of Smart Float in production on Evergreen 2.2. I've committed a lightly tested version for Master in my working repository. The implementation is almost entirely plpgsql code and no Evergreen client side interface currently exists, but I wanted to put it out to the community at this point in the hopes of finding collaborators and getting it included in future releases.
[OPEN-ILS-DEV] April developers meeting
Hi all, It's time to schedule the monthly Evergreen developers meeting. The meeting poll is available at http://doodle.com/ze47agcsia9mdhdb. Let us know when you're available! Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] Need feedback for planning IRC "practice time" meeting
Hi Yamil, I just looked at the community calendar and didn't see anything that would conflict with either of those times. +1 to either of those dates/times. +1 to an hour. Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 3/24/2014 2:38 PM, Yamil Suarez wrote: Hola, I promised to plan two IRC "practice time" meetings after the conference. I wanted to see if it would be OK to shoot for the first one to happen sometime this Thursday (March 27) OR Friday (March 28) at 2 PM EST. BTW, I am not sure if I want to have the meeting be an hour or just half an hour. I want to give enough time for stragglers to join in and participate. I will have some online slides that I will post that has explanations, and that will take some time for participants to read through. Thoughts? Thanks in advance, Yamil
Re: [OPEN-ILS-DEV] Shared "Maintenance" Account for Launchpad?
I like it! I've already created a filter for that e-mail address and was happy to see those notifications quietly go in the trash. Could we use it for changing milestones too? Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 3/11/2014 1:26 PM, Dan Wells wrote: Thanks for +1, Galen. To help others better evaluate this idea, I've gone ahead and created a new account and used it for a test run (setting 2.5.3 bugs from 'Fix Committed' to 'Fix Released'). The account name is "Evergreen Bug Maintenance", and the email address (for filter purposes) is bugmas...@evergreen-ils.org. This is just a trial run at this point, more feedback is welcome. Thanks, Dan Daniel Wells Library Programmer/Analyst Hekman Library, Calvin College 616.526.7133 -Original Message- From: open-ils-dev-boun...@list.georgialibraries.org [mailto:open-ils-dev-boun...@list.georgialibraries.org] On Behalf Of Galen Charlton Sent: Wednesday, March 05, 2014 2:02 PM To: Evergreen Development Discussion List Subject: Re: [OPEN-ILS-DEV] Shared "Maintenance" Account for Launchpad? Hi, On Wed, Mar 5, 2014 at 7:39 AM, Dan Wells wrote: Here's an idea I had a while back which I think would make the Launchpad email system more useful. As it stands, the system sends out an email for every little change, and, from my perspective, the more meaningful changes sometimes get lost in the noise. I think we would benefit from a shared "maintenance" account which bug wranglers, RMs, or whoever else could use to do more systematic and routine edits. This seems like a reasonable work-around to me. +1 Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: g...@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web:http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
[OPEN-ILS-DEV] Evergreen performance evaluation
Hi all, I've been remiss in sharing this information with the list. As many of you know, MassLNC contracted with OmniTI last spring to conduct a performance evaluation of Evergreen. There have been a few Launchpad bugs created to incorporate some database optimizations recommended by their PostgeSQL analyst, but they also delivered a report to use in December with recommendations and findings from the evaluation. I posted the report on the Evergreen wiki at http://wiki.evergreen-ils.org/doku.php?id=dev:testing:performance_report. Our hope is that the report will lead to discussions in the developer community that may lead to other ideas to improve performance in Evergreen. Thank you, Kathy -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-DEV] a request regarding development communication in the bug tracker
Hi Chris, Thank you for sending this e-mail! For the past week, I've been mulling over the issue of how we can improve the process of proposing development projects, particularly those that are large in scale or change existing functionality, and to see more collaboration among developers earlier on in the process. I think we can all agree there was a breakdown in the process for this particular project. Development plans were shared early on through Launchpad and through an e-mail to the general list. However, I think one constant challenge is capturing the attention of fellow developers to get their feedback at the time you need it. Let's face it, we're all busy, and we all have been in a situations where we're so wrapped up in other projects (i.e. our jobs) that we might not be able to give feedback on a project at the time it is sought. Sometimes, you hit gold and you get a lot of early feedback that helps you adapt your development plans. But it doesn't always happen. I give a +1 for these discussions occurring on the general list, but I would like to think more about how to improve that collaboration early on to help the process run more smoothly. A couple of ideas I've had: - IRC discussions about a particular project need to be recorded somewhere. I understand that the real-time nature of IRC sometimes makes it easier to collaborate on a development project, but, once those conversations are over, they need to be recorded either on the Launchpad report or in the ongoing e-mail thread. I would like to see reservations or support for a particular development approach to be recorded in the LP report or e-mail thread as well. - I would like to propose that proposals for large development projects or those that change existing functionality be placed on the agenda for developers meetings. The plans should be shared a few days before those meetings to give developers a chance to review them. I think this helps the issue where development projects shared via the proper channels don't always receive the feedback they otherwise would have received if everyone were paying close attention. The developers meetings are one time during the month where one developer can get the attention of all the other committers in the community. Of course, the results of those discussion should also be recorded in any ongoing e-mail threads. Thanks again Chris! Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 3/5/2014 8:58 AM, Sharp, Chris wrote: Good Morning All, I've had my head down with local projects since early January, so I'm just now able to tune in a bit on 2.6 development. I was just chatting with Ben Shum about some 2.6 new features and I came across the discussion happening on https://bugs.launchpad.net/evergreen/+bug/1198465. The discussion goes pretty deeply into the rationale for the features being proposed and/or developed, and I would like to request that those sorts of discussions happen here on this list rather than within the dark depths of Launchpad. I happen to subscribe to Launchpad bug mail, so I get every communication of new bugs, status changes, and comments added, but I don't always have the time/bandwidth to tune in to every email that comes through (especially during bug retargeting times like now). I do, however, read every email that comes to this and the Open-ILS-General lists. When I first started learning about the inner workings of Free and Open Source Software projects, I purchased "Producing Open Source Software" by Karl Fogel (http://producingoss.com/), which I think is a great guide for projects like ours written by a veteran of the Subversion project (one of our SFC cousins, incidentally). In his chapter on communication, he has a section entitled "No Conversations in the Bug Tracker", that I think is worth a read: http://producingoss.com/en/bug-tracker-usage.html. Given the availability and higher visibility of this list, the difficulty of navigating/searching Launchpad, and perhaps most importantly, the fact that we have recurring discussions about ditching Launchpad in favor of some other bug tracker, I'd like to request that we have discussions like the one on bug 1198465 on the public lists instead. I'm welcome to alternative opinions on this, so feel free to respond frankly! Thanks, Chris
Re: [OPEN-ILS-DEV] February 2014 developers meeting
Hi all, The next Evergreen developers meeting is scheduled for Wednesday, February 12 at 2 p.m. Eastern, 11 a.m. Pacific, 19:00 UTC. A draft agenda is available at http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-02-12. Feel free to add any discussions items to the agenda. Is anyone interested in running the meeting? Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 2/5/2014 8:04 AM, Kathy Lussier wrote: Hi all, It's time to schedule the February Evergreen developers meeting. Doodle poll is available at http://doodle.com/shbpr649h6xint7r. Kathy
