| 00:22 |
|
jvwoolf joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:30 |
|
rjackson_isl_hom joined #evergreen |
| 08:13 |
|
mantis1 joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 11:02 |
Dyrcona |
Yeahp. |
| 11:07 |
Dyrcona |
The places in the OpenSRF code where the errors are coming from look like it would be on first connection or getting the first response from ejabberd. |
| 11:09 |
Dyrcona |
RE Chrome issues from yesterday: I've also had to reload GMail more frequently to it to autofill email recipients. |
| 11:11 |
csharp_ |
ulimit shows 'unlimited' for every user we've tested opensrf, root, ejabberd |
| 11:11 |
csharp_ |
@quote add < Dyrcona> csharp_: My gut could be wrong. I am hungry at the moment. |
| 11:11 |
pinesol |
csharp_: The operation succeeded. Quote #221 added. |
| 11:12 |
csharp_ |
oh - didn't mean to keep the csharp_ part :-) |
| 11:17 |
Dyrcona |
:) |
| 14:45 |
Dyrcona |
terranm++ |
| 14:46 |
terranm |
https://bugs.launchpad.net/evergreen/+bug/1958573 |
| 14:46 |
pinesol |
Launchpad bug 1958573 in Evergreen "Action triggers that create messages for Patron Message Center are setting visiblity to false" [High,New] |
| 14:46 |
terranm |
patch ready for testing |
| 14:46 |
Dyrcona |
Yeah, I got the email. I've not seen it in the wild, but I think looking at the code qualifies me to confirm it. |
| 14:49 |
mmorgan |
terranm++ |
| 14:54 |
|
terranm joined #evergreen |
| 16:33 |
|
jihpringle joined #evergreen |
| 17:03 |
|
mmorgan left #evergreen |
| 17:52 |
|
mantis1 joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:08 |
|
jihpringle joined #evergreen |
| 19:44 |
|
jihpringle joined #evergreen |
| 23:08 |
|
Keith_isl joined #evergreen |
| 04:50 |
|
alynn26 joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
Christineb joined #evergreen |
| 07:54 |
|
collum joined #evergreen |
| 08:31 |
|
mantis joined #evergreen |
| 09:38 |
|
jvwoolf joined #evergreen |
| 09:50 |
Dyrcona |
miker: Yes. The TTOPAC pulls titles and authors from the MARC, IIRC. BooPAC uses display fields. |
| 09:53 |
mmorgan |
JBoyer++ |
| 10:50 |
mantis |
We're on 3.6.5 using Angular for the staff but still using TPAC for the OPAC. When accessing the Patron View button on conjoined items, we get a server error. This however works when Boopac is enabled on our other test servers. Is this a known bug? |
| 11:06 |
Dyrcona |
mantis: IDK, but if it is not on Lp, then it's probably not widely known. |
| 11:41 |
|
jihpringle joined #evergreen |
| 12:15 |
collum |
mantis: We don't have any conjoined items, but I just tried it in our test database and it worked in the TPAC. We are on 3.7.2. |
| 12:17 |
mantis |
collum: Thanks for giving it a shot. With the community servers on Bootstrap, it's hard for us to tell if there is an issue on my end or an actual bug. |
| 12:43 |
|
jvwoolf1 joined #evergreen |
| 13:38 |
|
rfrasur joined #evergreen |
| 15:08 |
JBoyer |
Ah |
| 15:09 |
JBoyer |
In that case there should some good news in our email later I suppose. In short, you've got concerto and friends loading deterministically? |
| 15:09 |
JBoyer |
(again, that is) |
| 15:10 |
Dyrcona |
Yes. Test results are consistent. |
| 15:11 |
JBoyer |
Dyrcona++ |
| 15:11 |
Dyrcona |
And all pass, at least, the last few times that I tried. |
| 15:11 |
JBoyer |
Ok, I'm planning to skip release info updates for lack of non-placeholder-ness unless someone prefers that be changed. |
| 17:26 |
miker |
seems unlikely to have recently broken because of that, but I suppose it's possible. the opac email code lacks all the 2019/2020 updates that the reactor got. would be beneficial in any case to have them. I'll look at putting that in the branch as well |
| 17:26 |
miker |
but not tonight! |
| 17:26 |
terranm |
miker++ |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 05:42 |
|
jonadab joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 12:00 |
|
miker joined #evergreen |
| 12:05 |
|
gmcharlt joined #evergreen |
| 12:11 |
|
Dyrcona joined #evergreen |
| 13:59 |
Dyrcona |
Well, I still manged to mess it up. |
| 14:17 |
csharp_ |
Dyrcona: thanks for the info! |
| 14:22 |
Dyrcona |
csharp_: You're welcome. |
| 14:24 |
Dyrcona |
I believe I have something that works with savepoint. After 1 more test run with 1 item at a time, I'll take a break. After that, I'll write a program to test a mix of items that should fail and succeed. If that works, I'll make the necessary changes to the staff client, and then update the release notes and squash the branch again. |
| 14:26 |
Dyrcona |
Yeah, tests still work. Maybe I'll add the test of multiple copies to the live test file rather than write a whole new program.... |
| 16:07 |
Dyrcona |
So, I'm returning an array ref in the back end call. Are there examples of using such a thing in AngularJS? |
| 16:13 |
Dyrcona |
I think I can just use it as an array. We'll see. |
| 16:32 |
Dyrcona |
Anyone know if I can set values in a toast? I though I could just assign a field on $scope. |
| 16:47 |
Dyrcona |
Well, now my toast is empty.... |
| 16:54 |
Dyrcona |
I'll let this go for now and I might look into it later. I've already gone over time. |
| 17:53 |
|
mantis joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Installing AngularJS web client <http://testing.evergreen-ils.org/~live//archive/2022-01/2022-01-08_16:00:02/test.28.html> |
| 18:04 |
|
jvwoolf1 joined #evergreen |
| 18:32 |
JBoyer |
Oops, accidentally posted this on the feeds channel. So, if you are annoyed like I am about that stupid mess in the mile-long log above it appears to be a forgotten line that was supposed to be removed from the colors package: https://github.com/Marak/colors.js/blob/master/lib/index.js |
| 18:32 |
JBoyer |
I wonder how many more dependencies he pulled in to use .zalgo on that. 🙄 |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:42 |
|
Christineb joined #evergreen |
| 07:31 |
|
rjackson_isl_hom joined #evergreen |
| 08:20 |
|
rjackson_isl_hom joined #evergreen |
| 14:31 |
alynn26 |
me |
| 14:32 |
dluch |
dbs: you want to lead off? |
| 14:32 |
dluch |
(I switched the order of new business items, btw) |
| 14:33 |
dbs |
So first up: correction to my most recent post. |
| 14:33 |
dbs |
You can download the full set of documentation from every commit / branch in GitLab Pages |
| 14:33 |
dbs |
(nothing needs to be figured out, other than my overtired brain) |
| 14:34 |
dbs |
Second: in 3.0 best practice is still to keep a separate git repo for the base Antora build stuff. So I would revert that |
| 14:36 |
dbs |
Third: working in GitLab or GitHub these days feels like lightyears ahead of CLI-based git workflows, given integrated issue tracking, project planning, Web IDE for drive-by contributions, merge request reviewing, etc |
| 14:36 |
|
bott_grpl joined #evergreen |
| 14:36 |
dbs |
but that one is way outside of the scope of "making it easier to build and test docs" and a much bigger discussion |
| 14:36 |
alynn26 |
I actually like working in GitHub better than the CLI. :) |
| 14:37 |
Bmagic |
do we need to migrate the Evergreen repository to a gitlab server in order to get this? We've talked about it as a replacement for Launchpad in a different dev discussion a couple of years ago (probably more because you have to skip the pandemic year(s)) |
| 14:37 |
abneiman |
I definitely prefer a GUI also, but I've gotten accustomed to operating within the CLI to the point where I'd need a github refresher to do the same work there |
| 14:38 |
alynn26 |
A better way to build and test docs that is more intuitive is better. |
| 14:39 |
dbs |
Bmagic: hmm - I'm mirroring the git repo on GitLab (have been since it was on gitorious like ten years ago). I don't think a mirrored branch triggers a GitLab CI/CD thing but I can check |
| 14:40 |
abneiman |
alynn26: hard agree about streamlining build/test of docs - it's a major roadblock right now |
| 14:40 |
dbs |
it might be possible to trigger a rebuild using something like a particular branch name, like docs-build or something hacky... make that a to-do for me |
| 14:41 |
dluch |
Sure |
| 14:41 |
Dyrcona |
FWIW, we run gitlab at CW MARS mainly just to try it out. We don't do any fancy CI/CD stuff though. |
| 14:41 |
Bmagic |
Having our about-to-be submitted docs reviewed and integrated into the Evergreen Docs look and feel would be super tasty. The routine would be to submit your test changes to a certain pre-defined Git branch, and poof, a minute later, it's rendered on a page somewhere |
| 14:41 |
dbs |
alynn26 abneiman: even the small win of "can't merge this because you introduced an error" with a clear error message in the branch discussion is so nice |
| 14:42 |
dluch |
#action dbs will see if it's possible to trigger a rebuild using something like a particular branch name, like docs-build or something hacky |
| 14:42 |
alynn26 |
Clear error messages would be a win for me. |
| 15:51 |
|
_collum joined #evergreen |
| 15:59 |
|
mantis joined #evergreen |
| 16:14 |
|
jihpringle joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:42 |
|
collum joined #evergreen |
| 08:07 |
|
rjackson_isl_hom joined #evergreen |
| 08:15 |
|
mantis joined #evergreen |
| 11:46 |
miker |
and they're both restricted to 1 file, so, easy peasy |
| 11:46 |
csharp_ |
yep |
| 12:23 |
mmorgan |
Has anyone gathered some experience with 3.7+ in a production database with saving/loading bib records? We're trying to get an idea of the effect of the symspell dictionaries for did you mean. |
| 12:26 |
csharp_ |
mmorgan: we're going to 3.8 next month - running it on a training/testing server that is production-ish, datawise |
| 12:26 |
csharp_ |
what should we be looking out for? |
| 12:26 |
jeff |
We're not relying on "did you mean" and did not populate the related tables as part of our upgrade. I've noticed a deadlock or two which have made me want to look into disabling the relevant triggers until I have time to look into it more. |
| 12:28 |
jihpringle |
mmorgan: we're running 3.7.0 and do not have "did you mean" turned on. In testing with it on we couldn't save any MARC records |
| 12:29 |
jihpringle |
we haven't tested with any of the post 3.7.0 "did you mean" fixes yet |
| 12:29 |
mmorgan |
csharp_: Our big concern is loading records with 856 links. We do a lot of that, but general saving and loading of bib records via vandelay is our concern, too. |
| 12:31 |
mmorgan |
We've just begun testing with production data and so far are seeing the records with 856 links taking MUCH longer, also getting general.unknown error for some records that have failed to load. |
| 12:31 |
mmorgan |
jeff: Not sure what you mean by a 'deadlock' ? |
| 12:32 |
mmorgan |
jihpringle: We've loaded some of the post 3.7.0 fixes. |
| 12:32 |
berick |
jeff: if you decide to disable, mind sharing what all you disable? |
| 12:33 |
mmorgan |
We're very early in testing, and were just wondering if others were ahead of us and had experiences regarding saving/loading records. |
| 12:38 |
mmorgan |
jihpringle: Have you done anything other than turning off "did you mean"? My thinking is that even with it off, the sysmpell dictionaries in the database would still be updated without disabling triggers like jeff mentions. |
| 12:38 |
csharp_ |
mmorgan: a deadlock is a postgresql level problem where two processes are waiting on each other to release the lock on a paritcular tuple ("row") |
| 12:39 |
mmorgan |
csharp_: Ah. Ok, thanks. I think I've seen log entries complaining about tuples. |
| 12:39 |
jeff |
mmorgan: the postgresql logs will log a deadlock when the database detects that process X and process Y (and maybe process Z) are all waiting on things that each other are waiting on. It's one of the reasons that pingest doesn't do certain bib-related ingest things in parallel. |
| 12:45 |
pinesol |
csharp_: The operation succeeded. Quote #219 added. |
| 12:46 |
csharp_ |
when it comes down to it, aren't we all just "waiting for more data from parent"? |
| 12:48 |
* csharp_ |
is referring to the server error mentioned yesterday http://irc.evergreen-ils.org/evergreen/2021-12-14#i_497049 |
| 13:00 |
mmorgan |
testing a file of 1000 records with 856 links on our 3.7 test system is not looking good. 6% progress after an hour, and most failed. |
| 13:03 |
JBoyer |
There are a couple dym-related patches that you may not have depending on your 3.7.X version. Since they're all just function updates they can be applied anytime and absolutely should be if you don't have them. |
| 13:03 |
JBoyer |
Sadly, I don't actually have a list handy to refer to... |
| 13:05 |
jeff |
...and Launchpad search returns 101 open tickets on a search for "did you mean"... :-P |
| 16:49 |
JBoyer |
I quite enjoyed this log4j take: https://twitter.com/leanrum/status/1470954707120181253 |
| 17:01 |
|
mmorgan left #evergreen |
| 18:00 |
|
jihpringle joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:01 |
|
eglogbot joined #evergreen |
| 19:01 |
|
Topic for #evergreen is now Welcome to #evergreen (https://evergreen-ils.org). This channel is publicly logged. |
| 19:32 |
|
jihpringle joined #evergreen |
| 04:41 |
|
denials joined #evergreen |
| 04:41 |
|
tsadok joined #evergreen |
| 04:42 |
|
jweston_ joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 08:25 |
|
mantis joined #evergreen |
| 09:49 |
|
rfrasur joined #evergreen |
| 10:14 |
berick |
could play an error sound too |
| 10:14 |
jeff |
hah, I was just thinking of an amusing error sound. |
| 10:15 |
berick |
*sad trombone* |
| 10:23 |
jeff |
okay, yes. looks like I can happily call egAlertDialog within services/net.js for a method error. I might leave that in place on my test instance for a while and see what it surfaces. |
| 10:24 |
jeff |
in the case of missing pieces where I have a method error and added a second function to the promise to surface that error on that specific action, I end up with two egAlertDialogs. :-) |
| 10:32 |
jeff |
having recently upgraded, I find myself wanting a test instance with our previous version of Evergreen... oops. :-) |
| 10:40 |
|
bshum joined #evergreen |
| 10:42 |
jeff |
bah: |
| 10:42 |
jeff |
> We detected an application built with production configuration. Angular DevTools only supports development builds. |
| 10:59 |
|
mmorgan joined #evergreen |
| 11:21 |
|
abowling joined #evergreen |
| 11:47 |
|
Keith-isl joined #evergreen |
| 15:07 |
Dyrcona |
Mechanical wit, but then it runs out and you have to buy more. Plus it leaves bits all around. |
| 15:07 |
JBoyer |
Ok, people should feel free to #info up as they continue to join. |
| 15:07 |
JBoyer |
#topic Action Items from Last Meeting |
| 15:07 |
JBoyer |
#info JBoyer will test out the branch in lp 1947595 |
| 15:08 |
pinesol |
JBoyer: Error: Could not gather data from Launchpad for bug #1947595 (https://launchpad.net/bugs/1947595). The error has been logged |
| 15:08 |
JBoyer |
I'm as surprised as you all may be, but that did happen and the branch was even signed off on because it does the thing. Dyrcona ++ |
| 15:08 |
Dyrcona |
JBoyer++ |
| 15:18 |
pinesol |
Launchpad bug 1953044 in OpenSRF "Perl services can crash with a "Use of freed value in iteration" error" [Medium,Confirmed] https://launchpad.net/bugs/1953044 |
| 15:18 |
gmcharlt |
the latter two are currently in production at Equinox |
| 15:19 |
gmcharlt |
the first one is a little more prospective |
| 15:19 |
Dyrcona |
I'll see if I can make some time to test a couple of those. |
| 15:19 |
csharp_ |
these are the "think of the children!" branches you mentioned before |
| 15:19 |
gmcharlt |
yup |
| 15:21 |
JBoyer |
Sounds like a plan, hopefully all 3 of those can get some testing and make it in soon. Any other OpenSRF discussion? |
| 15:22 |
jeffdavis |
(testing some of those is on my todo list fwiw) |
| 15:22 |
JBoyer |
jeffdavis++ (and Dyrcona ++ and gmcharlt ++ ) |
| 15:22 |
JBoyer |
If not, and given the placholders holding places we can skip down to |
| 15:23 |
JBoyer |
#topic Launchpad Status |
| 15:27 |
csharp_ |
do we have a sense of how well Edge Just Works™? |
| 15:27 |
csharp_ |
and to be clear, we're talking about Edge that's based on Chrome, yes? |
| 15:27 |
Dyrcona |
I believe so. |
| 15:27 |
JBoyer |
So, with the fact that it's literally Chromium + MS sync instead of Google Sync it works pretty well. shulabear took the client for a test drive and found no potholes. |
| 15:27 |
alynn26 |
I know of several people who use it. it works great for them. |
| 15:28 |
csharp_ |
maybe support it with a huge YMMV warning? |
| 15:28 |
JBoyer |
Yeah, Not-Chromium Edge is no bueno, even for MS. |
| 15:28 |
shulabear |
I've encountered no issues with it in testing, as long as it's the Chromium version. |
| 15:28 |
csharp_ |
that's the way we support MacOS here in PINES |
| 15:28 |
csharp_ |
"feel free, but it's on you" |
| 15:29 |
mmorgan |
What does "supporting Edge" entail? |
| 15:31 |
csharp_ |
I guess Hatch should be in the mix of what "support" means too? |
| 15:32 |
JBoyer |
csharp_, it works fine as-is, just isn't yet on the Edge Extension thing. (though you can install it via the chrome web store I believe) |
| 15:32 |
csharp_ |
I don't have a strong feeling/preference either way, which I guess is effectively "yes" |
| 15:34 |
JBoyer |
It's also possible to test the Angular client with the linux version by setting CHROMIUM_BIN to the right path. (I don't actually recommend using my branch to add the edge npm launcher because there's no good way to handle missing browsers. :/ ) |
| 15:35 |
JBoyer |
I'm for it personally because it's extremely low effort and it's possible that local IT may standardize on it anyway so staff may as well know we'll make sure it works. |
| 15:36 |
alynn26 |
+1 |
| 15:36 |
gmcharlt |
+1 |
| 15:39 |
JBoyer |
oops. Let the minutes show that's 11, 0, 1, not that it was a close call. :) |
| 15:39 |
JBoyer |
#topic Support for Newer PostgreSQL Versions |
| 15:39 |
JBoyer |
Dyrcona, how's things? |
| 15:40 |
Dyrcona |
Well, there are branches, one of which has been tested and signed off. |
| 15:40 |
miker |
soon to be committed :) |
| 15:40 |
Dyrcona |
mker looked at the other and had some questions about the XML changes. I'll go back an make them more consistent, using local-name() instead of namespaces. |
| 15:41 |
Dyrcona |
I'd like to get this in before the next Evergreen release. (3.9?) |
| 15:41 |
miker |
seems likely, imo |
| 15:42 |
Dyrcona |
The tests all pass, but I think there are places, like located URIs where performance suffers on newer Pg versions. |
| 15:42 |
miker |
I think I owe eyes on an old branch for that, in particular |
| 15:43 |
Dyrcona |
my three big questions are: 1. I'd like the Stretch removal branch to go in first, so that we don't have to mess with stretch prerequisites. |
| 15:43 |
JBoyer |
That shouldn't be an issue for 3.9 |
| 15:46 |
miker |
that complicates or delays dealing with some performance issues in 11+ re CTEs, but that's just timing I guess |
| 15:47 |
Dyrcona |
Well, we could remove the non-versioned db prerequisite and word the read me to recommend 10 in production environments. |
| 15:48 |
miker |
And by that I mean CTEs may need 11+ only syntax changes to avoid speed regressions |
| 15:48 |
JBoyer |
True, I kind of meant "if we can knock them out" when I said "other than these problems" :) but since we've had 9.6 and 10 available for some time we should probably have 10 and 14 available for those who want to test |
| 15:50 |
gmcharlt |
yeah, "it works" is sufficient for offering the option to install with newer versions, but I think the production recommendations need to avoid known performance regressions |
| 15:50 |
JBoyer |
I can +1 that. |
| 15:51 |
mmorgan |
+1 |
| 15:57 |
shulabear |
Dyrcona++ |
| 15:57 |
JBoyer |
#topic Migrating to Angular 12 sooner than later? |
| 15:57 |
JBoyer |
berick, how does it look? |
| 15:58 |
berick |
oh sorry |
| 15:58 |
berick |
minus a few broken unit tests, my initial Ang 12 upgrade process worked as expected |
| 15:59 |
JBoyer |
The angular update site makes it look like we can make that jump without any real code changes, which is good. |
| 15:59 |
berick |
if we want to update before EG 3.9 I'd prefer sooner than later |
| 15:59 |
sandbergja |
berick: does the linter still work? I remember something about some linting changes |
| 15:59 |
berick |
yeah, it was not such a big doeal |
| 15:59 |
berick |
sandbergja: don't recall if I tested. I can, though, when I rebase |
| 15:59 |
sandbergja |
berick++ |
| 15:59 |
sandbergja |
thanks |
| 16:00 |
berick |
ideally we could pick a merge date and me and whoever else can help will get it merged |
| 16:38 |
miker |
jboyer++ |
| 16:38 |
|
mmorgan left #evergreen |
| 16:39 |
sandbergja |
claiming 1309 |
| 16:42 |
pinesol |
[evergreen|malexander] lp-1942645 term name uniqueness - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a11ce47> |
| 16:42 |
pinesol |
[evergreen|Jane Sandberg] LP 1942645: stamp upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e79df5d> |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 00:57 |
|
abowling1 joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:47 |
|
rjackson_isl_hom joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:52 |
|
rfrasur joined #evergreen |
| 12:02 |
mmorgan |
berick++ # bug 1954301 |
| 12:02 |
pinesol |
Launchpad bug 1954301 in Evergreen "Hatch Browser Extension Sometimes Fails to Respond" [High,Confirmed] https://launchpad.net/bugs/1954301 - Assigned to Bill Erickson (berick) |
| 12:11 |
mmorgan |
berick: Assuming no issues are found with your patch, how does the fix proceed? Does it just come down to an update to the Chrome extension? Just wondering if we should start loading the unpacked extension on affected workstations. |
| 12:17 |
berick |
mmorgan: once it's merged, I'll post it to the Chrome store. after that, the extension should automatically update in the browser. |
| 12:18 |
berick |
csharp_: wondering if you have any cycles to test the extension changes in Firefox... https://launchpad.net/bugs/1954301 |
| 12:18 |
pinesol |
berick: Error: Could not gather data from Launchpad for bug #1954301 (https://launchpad.net/bugs/1954301). The error has been logged |
| 12:18 |
berick |
i'll try to do the same today |
| 12:18 |
mmorgan |
berick: ok, thanks! |
| 12:20 |
mmorgan |
jeff++ |
| 12:20 |
* jeff |
waves |
| 12:34 |
jeff |
oh hey, i should probably remove the .firefox from the this filename if I expect it to work: org.evergreen_ils.hatch.firefox.json |
| 12:42 |
berick |
my initial FF tests show the extension changes working as expected |
| 12:42 |
jeff |
hah, beat me to it. |
| 12:51 |
jeff |
tests well here on 96.0b3 for macOS |
| 12:52 |
jeff |
I can sign off and commit if you want to do the chrome/firefox extension bits on a Friday... |
| 12:57 |
JBoyer |
Does anyone need to print receipts on a weekend? |
| 12:57 |
JBoyer |
;D |
| 13:01 |
berick |
jeff: i'll be squashing the commit post-sign if that's OK w/ you (to remove some cruft, add some more code comments) |
| 13:03 |
jeff |
feel free either way. i haven't pushed a signoff but i could do one after if you like. |
| 13:04 |
berick |
ok, thanks |
| 13:04 |
berick |
lemme push a cleanup.. |
| 13:07 |
jeff |
We did encounter this on a few workstations this week after our upgrade, but when I went looking for workstations to test on, there appeared to be none that still had the issue... so, I'm confirming that it doesn't break anything that I can see, the fix looks logical, and I'm relying on mmorgan and others to confirm that it is an effective fix. :-) |
| 13:08 |
* mmorgan |
has been working in the client with the new extension and has seen no issues. |
| 13:09 |
mmorgan |
But I do wonder about deploying on a Friday... |
| 13:10 |
berick |
jeff: pushed user/berick/lp1954301-ext-tab-message-order-v2 w/ a single cleaned up commit. |
| 15:08 |
|
jvwoolf joined #evergreen |
| 16:22 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
