| Time |
Nick |
Message |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:20 |
|
JBoyer joined #evergreen |
| 07:22 |
|
kmlussier joined #evergreen |
| 07:31 |
|
agoben joined #evergreen |
| 07:48 |
kmlussier |
dbs: Is there an LP bug for the web app work you're doing? |
| 07:49 |
|
pgardella joined #evergreen |
| 07:51 |
|
pgardella joined #evergreen |
| 08:16 |
pgardella |
jeffdavis: Thank you. That was it. |
| 08:41 |
|
maryj joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:47 |
|
bos20k joined #evergreen |
| 08:57 |
|
Dyrcona joined #evergreen |
| 09:02 |
|
_adb joined #evergreen |
| 09:15 |
bshum |
kmlussier: I think dbs means for https://bugs.launchpad.net/evergreen/+bug/1681095 to be part of it, along with what's happening with dojo removal in https://bugs.launchpad.net/evergreen/+bug/1411699 |
| 09:15 |
pinesol_green |
Launchpad bug 1681095 in Evergreen "Extend browser cache-busting support for all stylesheets, JavaScript, and images in default public catalogue" [Undecided,Confirmed] |
| 09:15 |
pinesol_green |
Launchpad bug 1411699 in Evergreen "TPAC: Don't load dojo widgets unless we actually need them (for autocomplete)" [Wishlist,Confirmed] |
| 09:16 |
kmlussier |
bshum: Thanks! |
| 09:28 |
|
yboston joined #evergreen |
| 09:43 |
|
JBoyer joined #evergreen |
| 09:56 |
|
mmorgan1 joined #evergreen |
| 10:02 |
Dyrcona |
If you're going to purge/age circulations, then do it from the beginning and keep it up. |
| 10:03 |
Dyrcona |
Don't wait until you have 50 million rows in action.circulation. |
| 10:03 |
|
mmorgan joined #evergreen |
| 10:06 |
berick |
Dyrcona: indeed |
| 10:07 |
Dyrcona |
The purge function has been running for 40 days on my training server. I'm speaking from experience. :) |
| 10:07 |
berick |
had to tweak the purge script locally to add a max run duration so we could do it in nightly batches |
| 10:08 |
berick |
yowza 40 days |
| 10:08 |
kmlussier |
40 days and 40 nights |
| 10:08 |
Dyrcona |
yeah. ;) |
| 10:09 |
Dyrcona |
It will be 40 days at noon: 39 days 22:08:04.567928 |
| 10:09 |
Dyrcona |
berick: Your modifications would be of interest to me. Could you share them somewhere? |
| 10:12 |
berick |
Dyrcona: yeah. looking closer, we added start and end dates to the purge function (i.e. purge circs between this range) then the script that calls it exits after a configured duration. |
| 10:12 |
berick |
so purge a few months, check duration, purge a few more months, etc. |
| 10:14 |
Dyrcona |
berick: Sounds tedious enough. :) |
| 10:14 |
rhamby |
somehow "my script has been running for 40 days and 40 nights" sounds like the basis of an IT country and western song ... a genre we do not need |
| 10:15 |
* Dyrcona |
sings "Forty days and forty nights since you left me...." |
| 10:16 |
Dyrcona |
Somehow, I think there is a country western with an identical line in it. |
| 10:18 |
Dyrcona |
berick: How do you top it after the duration without losing the transaction? I should probably look that up, instead.... ;) |
| 10:19 |
berick |
Dyrcona: each chunk of months is its own transaction. the sql runs to completion each time, then the calling script checks to see if it should start another one. |
| 10:19 |
Dyrcona |
Oh. I see. Thanks. |
| 10:20 |
Dyrcona |
I should test this on my new hardware, but we're putting it in production on the 20th, so it may not finish by then. |
| 10:20 |
|
bwicksall joined #evergreen |
| 10:23 |
berick |
hm, so we have a custom circ purge script. it has less (unused locally) logic. it's diverged enough from stock I don't have a functional diff to share. but the gist is only work on circs whose xact_finish value falls between start_time and end_time, those being new function params. |
| 10:25 |
|
terran joined #evergreen |
| 10:27 |
Dyrcona |
rhamby: Muddy Waters wrote a song, "Forty Days and Forty Nights", so IT Blues might be a viable genre. :) |
| 10:29 |
rhamby |
Dyrcona: I'd listen to the Muddy Waters song, not sure about the 'homage' |
| 10:31 |
Dyrcona |
rhamby: Here you go: https://www.youtube.com/watch?v=WN-wZ6gdchc |
| 11:05 |
|
mmorgan1 joined #evergreen |
| 11:13 |
|
rlefaive joined #evergreen |
| 11:17 |
* JBoyer |
apparently missed a chance to riff on having a pickup truck full of PowerEdge servers when his dog left him. Twangy-twang, sad song, etc. |
| 11:46 |
pinesol_green |
Showing latest 5 of 6 commits to Evergreen... |
| 11:46 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1189989: Add suspend option when placing hold - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1c88f4c> |
| 11:46 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1189989: Add suspend option when placing hold - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fcdcab1> |
| 11:47 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1189989: Release notes entry for suspend option when placing hold - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=901bb58> |
| 11:47 |
pinesol_green |
[evergreen|Galen Charlton] LP#1189989: (follow-up) ignore invalid thaw date - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=64008ef> |
| 11:47 |
pinesol_green |
[evergreen|Galen Charlton] LP#1189989: (follow-up) normalize capitalization of "onclick" - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ccb7382> |
| 11:47 |
|
rlefaive_ joined #evergreen |
| 12:04 |
|
pgardella joined #evergreen |
| 12:28 |
|
Christineb joined #evergreen |
| 13:03 |
|
pgardella joined #evergreen |
| 13:14 |
|
terran joined #evergreen |
| 13:19 |
|
DPearl joined #evergreen |
| 13:33 |
|
gsams joined #evergreen |
| 13:35 |
gsams |
jeff: thanks for the query, looks like things were clean otherwise, just those fields I mucked up last go around. |
| 13:38 |
|
mdriscoll joined #evergreen |
| 14:11 |
jeffdavis |
jeff: a while back we were talking about a PatronAPI shim - is that any closer to being shareable? (I know you must have many higher priorities...) |
| 14:17 |
gmcharlt |
here's another call for agenda item's for today's dev meeting - https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-08-02 |
| 14:17 |
gmcharlt |
in just 43 minutes from now |
| 14:17 |
Dyrcona |
gmcharlt++ I was about to check my chat logs for the link. |
| 14:19 |
Dyrcona |
Looks like a fairly full agenda to me. |
| 14:37 |
pinesol_green |
[evergreen|Martha Driscoll] LP#1705478: Marc_export should include call number prefix and suffix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9720422> |
| 14:37 |
pinesol_green |
[evergreen|Galen Charlton] LP#1705478: (follow-up) emit prefix subfield before call number - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=41f9a3b> |
| 14:37 |
pinesol_green |
[evergreen|Galen Charlton] LP#1705478: add release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f0f8869> |
| 14:40 |
|
agoben joined #evergreen |
| 14:47 |
|
JBoyer joined #evergreen |
| 14:55 |
gmcharlt |
dev meeting in five minutes! |
| 15:00 |
gmcharlt |
and, it is that happiest time of the day |
| 15:00 |
gmcharlt |
#startmeeting Evergreen Development meeting, 2 August 2017 |
| 15:00 |
pinesol_green |
Meeting started Wed Aug 2 15:00:30 2017 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:00 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:00 |
pinesol_green |
The meeting name has been set to 'evergreen_development_meeting__2_august_2017' |
| 15:00 |
gmcharlt |
#info Agenda is https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-08-02 |
| 15:00 |
gmcharlt |
#topic Introductions |
| 15:00 |
gmcharlt |
please introduce yourselves |
| 15:00 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 15:00 |
gmcharlt |
#info gmcharlt = Galen Charlton, Equinox, RM |
| 15:01 |
DPearl |
#info DPearl = Dan Pearl, C/W MARS Inc. |
| 15:01 |
phasefx |
#info phasefx = Jason Etheridge, Equinox |
| 15:01 |
dbwells |
#info dbwells = Dan Wells, Hekman Library (Calvin Collge) |
| 15:01 |
JBoyer |
#info JBoyer = Jason Boyer, IN State Library |
| 15:01 |
Dyrcona |
#info Dyrcona = Jason Stephenson, C/W MARS Inc. |
| 15:02 |
jeffdavis |
#info jeffdavis = Jeff Davis, Sitka |
| 15:02 |
abowling |
#info abowling = Adam Bowling, Emerald Data Networks |
| 15:02 |
berick |
#info berick Bill Erickson, KCLS |
| 15:02 |
cesardv |
#info cesardv = Cesar Velez, Equinox |
| 15:03 |
rhamby |
#info, rhamby = Rogan Hamby, Equinox Open Library Initiative |
| 15:03 |
|
remingtron joined #evergreen |
| 15:03 |
gmcharlt |
so, moving |
| 15:03 |
remingtron |
#info remingtron = Remington Steed, Hekman Library (Calvin College) |
| 15:03 |
gmcharlt |
#topic Past action items |
| 15:04 |
gmcharlt |
JBoyer: from the last meeting you had an item to write up the open-ils.search backends disapearing issue |
| 15:05 |
gmcharlt |
and at least one part of it was identified as being due to the misspelled signal name |
| 15:05 |
JBoyer |
Let me find the LP number, but I believe most of it was actually running out of file descriptors for ejabberd. |
| 15:05 |
gmcharlt |
but a general question - is there more to it? |
| 15:06 |
JBoyer |
ah, it was bug 1697029 |
| 15:06 |
pinesol_green |
Launchpad bug 1697029 in OpenSRF "Service Listeners Crash when Using an Undefined Value for Syscalls" [High,New] https://launchpad.net/bugs/1697029 |
| 15:06 |
Dyrcona |
Oh, yeah a failure to fork, right? |
| 15:08 |
gmcharlt |
ok, then it sounds like it's worth split that bug up a bit |
| 15:08 |
JBoyer |
No, children would fork but then be gone as they were pulled from the idle list to take requests. It turned out ejabberd was ignoring their attempts to login and sometimes their giving up and dying was hitting just between being chosen to recieve a message and actually sending it. |
| 15:08 |
abowling |
wasn't that a movie with matthew mcconaughey and sarah jessica parker? |
| 15:08 |
gmcharlt |
- SIGARLM |
| 15:08 |
gmcharlt |
- documenting file descriptor limits during installation |
| 15:08 |
gmcharlt |
- documenting removing shapers during installation |
| 15:09 |
gmcharlt |
have I got it? |
| 15:09 |
JBoyer |
Yeah; my SIGALRM patch was only to silence log entries related to retrieving facets. |
| 15:10 |
jeffdavis |
Bill's patch also prevents the service from dying when the issue arises. |
| 15:10 |
JBoyer |
I would consider 2 and 3 to go hand-in-hand (these are all of the things you should do to ejabberd...) so that is all that likely needs to be addressed further since the SIGALRM patch has already gone in. |
| 15:11 |
jeffdavis |
So we might want to consider pushing that patch to master. Not a separate issue per se but wouldn't want to lose track of that. |
| 15:11 |
gmcharlt |
berick: so, would you take an action item to clean up that patch for submission? |
| 15:11 |
gmcharlt |
I can deal with the documentation issues (and this is all leading on the the next topic in the agenda, it looks like) |
| 15:11 |
berick |
gmcharlt: yep. pushing back to same bug? |
| 15:12 |
gmcharlt |
berick: yeah |
| 15:12 |
berick |
k |
| 15:12 |
gmcharlt |
#action berick will tidy up his patch for bug 1697029 and mark it for submission |
| 15:12 |
pinesol_green |
Launchpad bug 1697029 in OpenSRF "Service Listeners Crash when Using an Undefined Value for Syscalls" [High,New] https://launchpad.net/bugs/1697029 |
| 15:12 |
JBoyer |
berick++ |
| 15:12 |
gmcharlt |
#action gmcharlt will open and work on bugs for documentation changes for better ejabberd configuration during installation of OpenSRF |
| 15:13 |
gmcharlt |
so, rolling into the next topic |
| 15:13 |
gmcharlt |
#topic OpenSRF release |
| 15:13 |
gmcharlt |
so, in addition to what we just discussed, bug 1702978 strikes me as another good thing to merge in for 2.5.1 |
| 15:13 |
pinesol_green |
Launchpad bug 1702978 in OpenSRF "memcache keys containing % fail" [High,Confirmed] https://launchpad.net/bugs/1702978 |
| 15:14 |
gmcharlt |
any other high priorities for that maintenance release? |
| 15:14 |
gmcharlt |
also, I wanted to raise something I mentioned in the comments for that bug |
| 15:15 |
gmcharlt |
namely, I'd like to propose a convention that minor releases of OpenSRF will never change the C ABI |
| 15:15 |
gmcharlt |
(unless absolutely necessary to deal with a security issue) |
| 15:15 |
Dyrcona |
Question: What a minor relase? x.y or x.y.z? |
| 15:15 |
miker |
#info miker = Mike Rylander, EOLI (doh!) |
| 15:16 |
gmcharlt |
that would mean that for minor upgrades, it would be sufficient to recompile and reinstall OpenSRF and restart services, but dependent software (like Evergreen) wouldn't need to be recompiled |
| 15:16 |
gmcharlt |
Dyrcona: I'm thinking x.y.z |
| 15:17 |
Dyrcona |
OK. Thanks. |
| 15:18 |
miker |
gmcharlt: fwiw, +1 to your proposal as a rule |
| 15:19 |
Dyrcona |
Yes, I agree. +1 |
| 15:19 |
gmcharlt |
cool; I'll also raise it on open-ils-dev |
| 15:19 |
berick |
+1 |
| 15:19 |
gmcharlt |
so, moving on |
| 15:19 |
gmcharlt |
#topic Evergreen releases |
| 15:20 |
gmcharlt |
#info Evergreen 2.11.7 and 2.12.4 released on 28 July |
| 15:20 |
gmcharlt |
kmlussier+ |
| 15:20 |
gmcharlt |
kmlussier++ |
| 15:20 |
gmcharlt |
dbwells++ |
| 15:20 |
gmcharlt |
Bmagic++ |
| 15:20 |
gmcharlt |
#info Second feedback fest will run from 7 to 11 August |
| 15:21 |
gmcharlt |
#action gmcharlt will send out the list of pull requests (for recordkeeping purposes) on Friday |
| 15:21 |
gmcharlt |
also, if folks have suggestions for improving the feedback fest process, please speak up |
| 15:22 |
gmcharlt |
#info Reminder - feature slush is 18 August. Slush means that major enhancements should at least have a plausible pull request in place by that date |
| 15:22 |
kmlussier |
I'm having trouble remembering the process, but I think it went well last time. |
| 15:23 |
gmcharlt |
#nfo Reminder - feature freeze and string slush is 1 September |
| 15:23 |
miker |
kmlussier: I think of it as a bug squashing week for new features (wishlist bugs on LP) |
| 15:23 |
gmcharlt |
and anything that has a pull request, really |
| 15:24 |
gmcharlt |
there are already a set of big pull requests pending - eliminated staged search, webstaff offline circulation, patron batch edit |
| 15:24 |
gmcharlt |
and a couple more coming down the pike this week, including the web staff serials branch |
| 15:25 |
gmcharlt |
I think, generally speaking, master can be expected to be more than usually unstsable this month |
| 15:26 |
JBoyer |
Exciting. |
| 15:26 |
gmcharlt |
any other questions/comments regarding Evergreen releases? |
| 15:26 |
kmlussier |
yes, I have a question about hatch in 3.0. |
| 15:27 |
kmlussier |
Will users still need to do the current installation method for hatch in 3.0? Or are we planning to make it an official Chrome plug-in at some point. |
| 15:27 |
gmcharlt |
kmlussier: good question! I'm hoping that we can get it into the Chrome app store by October |
| 15:28 |
kmlussier |
Great! Thanks gmcharlt! |
| 15:28 |
gmcharlt |
also, one of the things that's been in the back of my mind is putting out a proposal to, this month, add a service to Evergreen that can store workstation settings server-side |
| 15:29 |
JBoyer |
It's still a 2-step process though, correct? The Chrome plugin and the native binary? Otr is there a way to bundle them together? |
| 15:29 |
gmcharlt |
which would mean that the only function that would be relegated to Hatch is helping to mediate printing, at least in cases where browser printing simply won't work |
| 15:30 |
berick |
JBoyer: still 2-step. chrome store would make one of those steps much simpler. |
| 15:30 |
JBoyer |
++ |
| 15:30 |
kmlussier |
I like the idea of storing it all server side. |
| 15:30 |
berick |
+1 from me too on server-side WS settings |
| 15:30 |
abneiman |
+1 to server-side storage (from the peanut gallery) |
| 15:30 |
JBoyer |
This is where I come in asking about how to determine what is a workstation setting vs a user setting. |
| 15:30 |
phasefx |
+1 |
| 15:31 |
JBoyer |
(Also +1 to gmcharlt's idea) |
| 15:31 |
gmcharlt |
JBoyer: that is an excellent question... that my proposal will TOTALLY SIDESTEP for now :) |
| 15:31 |
berick |
can we pretty please call it cloud storage? |
| 15:31 |
JBoyer |
Because cat templates as a workstation setting won't fly here, and I'm not up enough on Angular to get user settings to work in the web copy editor... |
| 15:31 |
gmcharlt |
berick: no |
| 15:32 |
gmcharlt |
berick: clouds cannot support ducks |
| 15:32 |
gmcharlt |
;) |
| 15:32 |
berick |
:) |
| 15:32 |
JBoyer |
HAh, berick++ |
| 15:32 |
gmcharlt |
JBoyer: specifically, what I'll propose will treat nearly everything that is currently stored in localStorage and/or Hatch associated with the workstation |
| 15:33 |
JBoyer |
I'll throw out the strictest definition here and others can argue it later: If it isn't dependant on hardware, it's not dependant on the workstation. (i.e. printing is about it. Maybe sound,) |
| 15:33 |
gmcharlt |
for the sake of getting something done quickly |
| 15:33 |
gmcharlt |
but I'd agree that there are some things that are more about staff members preferences |
| 15:33 |
JBoyer |
+1 to that, I'm just hoping that once they're moved over things can still be moved around. |
| 15:33 |
phasefx |
and yet staff may want different work environments for different things |
| 15:33 |
gmcharlt |
(but then you also get into the realm where some preferences a library might want to make enforceable policies) |
| 15:34 |
kmlussier |
Yes, what phasefx just said. |
| 15:34 |
berick |
gmcharlt: indeed.. column settings comes to mind |
| 15:34 |
JBoyer |
This new service needn't be limited solely to workstation prefs then... |
| 15:34 |
|
Jillianne joined #evergreen |
| 15:35 |
gmcharlt |
JBoyer: in the medium term, correct |
| 15:35 |
JBoyer |
it could be a simplified API to workstation and user prefs, allowing us to stop using PCRUD for some of it. |
| 15:35 |
gmcharlt |
yep, so that will make for a lively email thread, perhaps |
| 15:35 |
gmcharlt |
but moving on... |
| 15:36 |
JBoyer |
agreed, sorry. |
| 15:36 |
gmcharlt |
#topic Project to investigate alternatives to Launchpad and Gitolite |
| 15:37 |
gmcharlt |
not sure there's much to say at the moment |
| 15:37 |
Dyrcona |
Gitlab seems like it would be a workable replacement for gitweb and gitolite. |
| 15:38 |
gmcharlt |
but strikes me as something where we might have more breathing room to do it after 3.0 comes out? |
| 15:38 |
* gmcharlt |
is also leaning towards GitLab |
| 15:38 |
Dyrcona |
It would mean changes to repo structure. |
| 15:39 |
miker |
Dyrcona: are those changes written down somewhere? |
| 15:39 |
miker |
sorry if so and I missed it |
| 15:40 |
Dyrcona |
miker: Not yet, but I think the big thing would be favoring user repos over user branches in a single, working repo. |
| 15:40 |
miker |
Dyrcona: does it make "collab" branches harder, or just different? |
| 15:41 |
miker |
like, do I have to give gmcharlt full perms to allow him to push to a branch of mine? |
| 15:41 |
miker |
(SCARY!) ;) |
| 15:41 |
gmcharlt |
BOO |
| 15:41 |
Dyrcona |
You an do that with "group" or individual repos. |
| 15:42 |
cesardv |
https://github.com/gitlabhq/gitlabhq/pull/3597 Fork Pull Requests work in Gitlab |
| 15:42 |
Bmagic |
hey! I am here now |
| 15:42 |
Dyrcona |
I don't think the user has much control over permissions on branches, but you can grant write access to repos. |
| 15:42 |
miker |
would someone that's done some looking be willing to write (or at least seed) a doc on "how things would change"? |
| 15:42 |
Dyrcona |
I can do that. |
| 15:42 |
miker |
Dyrcona++ |
| 15:43 |
Dyrcona |
There are a few more things I want to look at anyway. |
| 15:43 |
gmcharlt |
#action Dyrcona will write some doc on how workflows might change with a switch to GitLab |
| 15:43 |
* csharp |
stumbles into the meeting |
| 15:44 |
gmcharlt |
so, moving on to new business |
| 15:44 |
gmcharlt |
#topic XUL client bug and backporting policy |
| 15:44 |
miker |
gmcharlt: proposal: NOPE |
| 15:44 |
miker |
:) |
| 15:45 |
gmcharlt |
heh |
| 15:45 |
* JBoyer |
would counter with "Nah" |
| 15:45 |
kmlussier |
I added that topic because there have been a handful of fixes lately that only apply to the xul client. I want clear guidance on when we stop merging them. |
| 15:45 |
gmcharlt |
or to qualify that a bit, my suggestion is that starting with the release of 3.0, XUL bugs will not get fixed unless (a) the problem is a security issue or (b) the problem is a clear data-destruction bug |
| 15:45 |
kmlussier |
I think there's still one out the with a pullrequest. |
| 15:46 |
csharp |
gmcharlt: +1 to your suggestion |
| 15:46 |
JBoyer |
Business as usual until the official 3.0 release is a good idea. |
| 15:46 |
kmlussier |
+1 |
| 15:46 |
JBoyer |
+a |
| 15:46 |
JBoyer |
uh, +1 |
| 15:46 |
miker |
+1 |
| 15:47 |
kmlussier |
:) |
| 15:47 |
Dyrcona |
+1 |
| 15:47 |
remingtron |
+1 |
| 15:47 |
csharp |
"oh, so we're doing letters now?" |
| 15:47 |
rhamby |
+1 |
| 15:47 |
gmcharlt |
csharp: digits are just too... new |
| 15:47 |
Dyrcona |
That's hex. JBoyer was trying to vote ten times. :) |
| 15:47 |
JBoyer |
it's 1vant gard. |
| 15:47 |
cesardv |
+1 |
| 15:47 |
berick |
to be clear, is that the same as no XUL merges allowed that don't meet a) and b) ? |
| 15:48 |
kmlussier |
a or b |
| 15:48 |
berick |
kmlussier: yes, thanks |
| 15:48 |
gmcharlt |
berick: I am tempted to say yes, essentially for the sake of making it clear that we REALLY MEAN IT when we say that the XUL client is deprecated |
| 15:49 |
jeffdavis |
I'm a bit hesitant about that change. |
| 15:49 |
miker |
gmcharlt: how about, "a NEW security issue" |
| 15:49 |
JBoyer |
It would also allow some older bugs to age out with an official WontFix status rather than a defacto one. |
| 15:50 |
jeffdavis |
Just because we've been testing the web client and finding things that are showstoppers for us in 2.12ish. So making 3.0 the cutoff seems a bit short. |
| 15:50 |
berick |
miker: heh, good point, "xul is old, needs update" ;) |
| 15:50 |
Dyrcona |
"Xul's dead." |
| 15:50 |
gmcharlt |
jeffdavis: yeah, those are things that need to be addressed, hopefully in time for 3.0.0 |
| 15:50 |
miker |
jeffdavis: have you been LP-ing them with a high priority? |
| 15:51 |
gmcharlt |
and it's not like the 3.0.x XUL client will be intentionally borken |
| 15:51 |
miker |
right |
| 15:51 |
kmlussier |
Yeah, I was continue working on those web client issues, it would be good to identify those that are real showstoppers for folks so that we priortize them. |
| 15:51 |
miker |
nor the 3.1 |
| 15:51 |
kmlussier |
Sorry, I can't do English today. |
| 15:52 |
jeffdavis |
I can at least commit to ensuring that we report 'em and prioritize accordingly. |
| 15:52 |
miker |
jeffdavis++ |
| 15:52 |
gmcharlt |
jeffdavis: that's very appreciated! |
| 15:53 |
miker |
*cough*timezones*cough* ;) |
| 15:53 |
jeffdavis |
ha :) |
| 15:53 |
kmlussier |
I have a few I could see being set to high priority too. |
| 15:54 |
berick |
so that's another question about xul getting broken.. some webstaff changes could potentially break XUL interfaces. changes to embedded UI's being the main culprit. at what point do we stop caring about those? |
| 15:54 |
miker |
after 3.1, I think |
| 15:54 |
kmlussier |
I was thinking 3.2, when we totally remove the xul client. |
| 15:54 |
berick |
so do we add that as c) to gmcharlt's xul merge list requirements? |
| 15:55 |
miker |
kmlussier: right, that's what I mean. don't break xul in 3.0 or 3.1 |
| 15:55 |
gmcharlt |
berick: yes |
| 15:55 |
gmcharlt |
#action gmcharlt will send a proposed XUL patch policy to open-ils-dev for feedback |
| 15:55 |
kmlussier |
miker: Ah, ok. I'm in total agreement with you then. |
| 15:56 |
gmcharlt |
moving on |
| 15:56 |
gmcharlt |
#topic Core Infrastructure Initiative Badge Program |
| 15:57 |
gmcharlt |
kmlussier: you're up |
| 15:57 |
kmlussier |
Very briefly, I would like to see if Evergreen has a shot at earning this badge. I have a volunteer from the community to help with going through the criteria, but was also looking for a volunteer to help with the more technical bits. |
| 15:57 |
kmlussier |
#link https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md |
| 15:58 |
kmlussier |
I figured we could divide it up according to see if Evergreen meets specific criteria and to find out which areas need more work. |
| 15:58 |
gmcharlt |
kmlussier: if nobody else volunteers... I'm interested, but not before October |
| 15:58 |
gmcharlt |
however, this strikes me as something that might be doable via open-ils-dev |
| 15:59 |
gmcharlt |
as some of the introspection might be better done out in the open |
| 15:59 |
miker |
and possilbly even on -general |
| 15:59 |
miker |
as not everything is code-related (thankfully) |
| 16:00 |
miker |
well... I take that back |
| 16:00 |
miker |
it's like 90% code |
| 16:00 |
kmlussier |
:) |
| 16:00 |
gmcharlt |
:) |
| 16:01 |
gmcharlt |
so, something for folks to think about |
| 16:01 |
gmcharlt |
we have reached the hour, but have two items for dev feedback |
| 16:01 |
kmlussier |
Yes, I was planning to share our progress on the list, whichever one it is. But it still requires people to take the initial look and see where there are questions. |
| 16:02 |
Dyrcona |
kmlussier: You could always ask for technical help on the dev list. |
| 16:02 |
berick |
i like the idea. taken as a whole it seems daunting. in smaller pieces on the dev list i'm sure we could suss it out. |
| 16:03 |
JBoyer |
The list is also a good way to see who has claimed what parts rather than searching IRC logs. |
| 16:03 |
berick |
gmcharlt: and i have a 3rd (small) dev request for feedback |
| 16:03 |
gmcharlt |
so, if kmlussier takes up the idea, are folks willing to commit to responding on open-ils-dev? |
| 16:04 |
miker |
I can certainly respond to specific questions, indeed |
| 16:04 |
gmcharlt |
also are folks willing to send up to 15 minutes on the dev review items (5 minutes apiece), or shall we close the meeting now? |
| 16:04 |
kmlussier |
yes |
| 16:04 |
miker |
I'm willing, but biased :) |
| 16:04 |
* berick |
will stick around |
| 16:04 |
JBoyer |
+1 the clock is still running. |
| 16:05 |
gmcharlt |
tick-tock |
| 16:05 |
Dyrcona |
I can stay. |
| 16:05 |
gmcharlt |
miker: so, speaking of time... |
| 16:05 |
miker |
prepare for a short monolog to start: |
| 16:05 |
miker |
some EG sites span timezones (see: sitka), and other could, easily. |
| 16:05 |
miker |
we added client timezone passing to opensrf, and use it in evergreen, as of opensrf 2.5 and eg 2.12 |
| 16:05 |
miker |
better timezone support would be really good, especially for due dates which are shifted to the end of the day |
| 16:05 |
miker |
there are several bugs for that... 1074195, 1703020 among them |
| 16:05 |
miker |
but, angular does not do "real" timezones on its date filter. only offsets: https://code.angularjs.org/1.6.5/docs/api/ng/filter/date |
| 16:06 |
miker |
in order to support proper time zones, we need something better. that better thing is the moment.js timezone module: http://momentjs.com/timezone/ |
| 16:06 |
miker |
(so sayeth the google and stack exchange) |
| 16:06 |
miker |
and the integration for that is in the branch on https://bugs.launchpad.net/evergreen/+bug/1705524 |
| 16:06 |
pinesol_green |
Launchpad bug 1705524 in Evergreen "Honor timezone of the acting library where appropriate" [Wishlist,New] |
| 16:06 |
miker |
that branch contains a mapping layer to translate between angular and moment "locale-aware" time formats such as "short" and "shortDate" on the angular side |
| 16:06 |
miker |
but there are minor mismatches, and the angular version is less close to the ISO standard for locale formatting |
| 16:06 |
miker |
so, I would like to override the built-in date filter in angular with a moment-based one |
| 16:07 |
miker |
... objections? |
| 16:07 |
JBoyer |
How far is less close? |
| 16:07 |
miker |
(pros: better support, more consistent UIs; cons: more JS to download) |
| 16:07 |
JBoyer |
(for those of us only now seeing it) |
| 16:07 |
Dyrcona |
No. I assume you're also looking for willing victims...er test subjects. |
| 16:07 |
miker |
JBoyer: zero-padding differences |
| 16:08 |
miker |
mainly |
| 16:08 |
JBoyer |
Hmm. |
| 16:08 |
miker |
and a huge lack of standard locale-aware formats in angular |
| 16:08 |
miker |
moment.js just supports everything |
| 16:08 |
miker |
angular sorta tries to |
| 16:08 |
Dyrcona |
Is the standards conformance better in later versions of Angular? |
| 16:08 |
miker |
so, I gues my mainly was misplaced ;) |
| 16:08 |
miker |
Dyrcona: nopers :( |
| 16:09 |
JBoyer |
Oh, if you mean that moment.js is closer to ISO that's not how I read it. |
| 16:09 |
miker |
Dyrcona: and it still doesn't undertand real timezones, just offsets |
| 16:09 |
miker |
JBoyer: that is what I meant, sorry |
| 16:09 |
miker |
basically, moment.js + moment-timezone = iso standard (as best as JS can manage) |
| 16:09 |
JBoyer |
Ah. |
| 16:10 |
Dyrcona |
Well, +1 from me for moment.js |
| 16:10 |
miker |
so, we /have/ to use moment sometimes (for any DST-aware timestamps) |
| 16:10 |
miker |
but I want to use it everywhere for consistency |
| 16:11 |
JBoyer |
Definitely +1 for all or nothing. As soon as you have to decide whether or not you can get away with using X or if you have to use Y things need to be rethought. |
| 16:12 |
miker |
right, same thought here. but, I'll be transparently replacing angular's date filter with a moment-based implementation |
| 16:12 |
miker |
so, figured best to ask around ;) |
| 16:12 |
gmcharlt |
ok - so five minutes are up for that discussion |
| 16:12 |
gmcharlt |
moving on to berick |
| 16:13 |
miker |
we could do it non-transparently, but that would mean touching tons of code, and likely reintroducing problems later |
| 16:13 |
miker |
gmcharlt: kk |
| 16:13 |
JBoyer |
Considering that my alternative is to only store UTC in the DB, treat :59:59 as magic, and do all offset math client side, this is as +1 an alternative as there can be. ;) |
| 16:13 |
berick |
this should be simple, do we want to wait until after 3.0 to update from angular 1.5 to 1.6 (bug #1680140) ? |
| 16:13 |
pinesol_green |
Launchpad bug 1680140 in Evergreen "Update staff JS dependencies for Angular 1.6" [Wishlist,Confirmed] https://launchpad.net/bugs/1680140 |
| 16:14 |
gmcharlt |
berick: I'm inclined to defer that decision to the week of 28 August |
| 16:14 |
berick |
i ask becuase any time we muck about in the js, espeically the deps it means re-testing, rebasing, etc. |
| 16:14 |
Dyrcona |
Given your comments from today, I'd say wait. |
| 16:14 |
gmcharlt |
i.e., give a try before the beta gets cut |
| 16:15 |
gmcharlt |
not that I'm particuarly opposed to waiting until after 3.0... but given our experience with Dojo, I think there's a strong argument to be made that we should get used to biting the version treadmill bullet |
| 16:15 |
gmcharlt |
(to thoroughly mix metaphors) |
| 16:16 |
berick |
gmcharlt: ok, works for me. i can help clean it up, just want to do it at the best time (i.e when the effort won't be wasted) |
| 16:16 |
csharp |
gmcharlt++ |
| 16:16 |
berick |
i'll add a note to the bug about revisiting |
| 16:16 |
gmcharlt |
ok |
| 16:16 |
gmcharlt |
so then, finally, back to miker about offline |
| 16:17 |
miker |
Really, I just want to get input on the serviceworker setup in use, and ask for testing |
| 16:17 |
csharp |
@band add The Version Treadmill Bullet |
| 16:17 |
pinesol_green |
csharp: Band 'The Version Treadmill Bullet' added to list |
| 16:17 |
miker |
we're using UpUp currently |
| 16:18 |
miker |
https://www.talater.com/upup/ |
| 16:18 |
miker |
which does the bare minimum to supply offline functionality |
| 16:18 |
miker |
rather than a whole serviceworker framework |
| 16:18 |
miker |
I see that as a plus -- list assets needed, it keeps them current |
| 16:19 |
miker |
if the network can't serve them, it will |
| 16:19 |
miker |
the branch is at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1706107-offline-mode |
| 16:19 |
miker |
LP at https://bugs.launchpad.net/evergreen/+bug/1706107 |
| 16:19 |
pinesol_green |
Launchpad bug 1706107 in Evergreen "Offline mode for the Web Client" [Undecided,New] |
| 16:20 |
kmlussier |
I've already done a fair amount of testing and could probably add a signoff sometime soon. I probably would want to load it on a local test server just to make sure it still works as I remember. |
| 16:20 |
JBoyer |
I'm +1 to using the simplest thing that will work, though I've not been able to test that branch yet. |
| 16:20 |
kmlussier |
miker: Are we losing anything by not using the whole serviceworker framework? |
| 16:20 |
miker |
kmlussier: complication? ;) |
| 16:21 |
miker |
seriously, not that I can see |
| 16:21 |
miker |
we just need something that can intercept network calls and serve content locally |
| 16:21 |
miker |
that is /all/ upup tries to do |
| 16:21 |
miker |
and, now that it's all set up, it seems to do well |
| 16:22 |
berick |
ditto JBoyer |
| 16:22 |
miker |
kmlussier: when testing the new separate branch (was embedded in serials before) we'll need to watch for new 404s during offline mode |
| 16:23 |
miker |
one key thing is that upup has to know about (and cache) every single resource that the offline interface references, either directly or indirectily, via css include or xhr also |
| 16:24 |
miker |
for instance, I had to install the woff2 version of the bootstrap font because, even though we don't use it, it's requested by the css |
| 16:24 |
miker |
and causes a load failure in the offline UI if it can't be cached by the service worker |
| 16:26 |
miker |
to sum up: this is a call for testing, and secondarily, a call for critique of the implementation |
| 16:26 |
kmlussier |
ok, I'll try to carve time out for testing it. I think I know what to look for and how to break it if there are issues. :) |
| 16:26 |
gmcharlt |
ok, and with that, we've reached the end |
| 16:26 |
miker |
kmlussier: if anyone does ... ;) |
| 16:26 |
miker |
thanks all |
| 16:26 |
gmcharlt |
thanks everybody! |
| 16:26 |
gmcharlt |
#endmeeting |
| 16:26 |
pinesol_green |
Meeting ended Wed Aug 2 16:26:52 2017 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:26 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2017/evergreen.2017-08-02-15.00.html |
| 16:26 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2017/evergreen.2017-08-02-15.00.txt |
| 16:26 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2017/evergreen.2017-08-02-15.00.log.html |
| 16:26 |
miker |
gmcharlt++ |
| 16:27 |
csharp |
gmcharlt++ |
| 16:27 |
phasefx |
gmcharlt++ |
| 16:27 |
kmlussier |
gmcharlt++ |
| 16:27 |
remingtron |
gmcharlt++ |
| 16:27 |
Dyrcona |
gmcharlt++ |
| 16:28 |
miker |
berick: btw, the minification bug will want to know about offline, and vice versa ... just noticed the update on -dev |
| 16:30 |
|
DPearl left #evergreen |
| 16:32 |
berick |
miker: k, yeah, that's another one that would benefit from a quick merge once it's updated. |
| 17:00 |
|
https_GK1wmSU joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:01 |
|
https_GK1wmSU left #evergreen |
| 17:05 |
|
mmorgan1 left #evergreen |
| 17:37 |
Bmagic |
gmcharlt++ |
| 18:44 |
|
https_GK1wmSU joined #evergreen |
| 18:46 |
|
https_GK1wmSU left #evergreen |
| 20:32 |
|
http_GK1wmSU joined #evergreen |
| 20:33 |
|
http_GK1wmSU left #evergreen |
