| Time |
Nick |
Message |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:05 |
|
kmlussier joined #evergreen |
| 07:05 |
kmlussier |
bshum++ |
| 07:05 |
kmlussier |
parts++ |
| 07:14 |
|
collum joined #evergreen |
| 07:15 |
|
_collum joined #evergreen |
| 07:16 |
JBoyer |
kmlussier++ |
| 07:16 |
JBoyer |
:D |
| 07:22 |
kmlussier |
Excellent! I have karma for one more year! Thanks JBoyer! |
| 07:31 |
|
rjackson_isl_hom joined #evergreen |
| 08:08 |
kmlussier |
I'll just leave this here - https://docs.google.com/spreadsheets/d/1U_9sQ9snIgF4TM9U39dD4XkjCUbbRxDHxjcqTP6gjlw/edit?usp=sharing and I'll see you all again around this time next year. Happy Friday! |
| 08:16 |
|
RFrasur joined #evergreen |
| 08:23 |
rhamby |
just in case anyone missed the registration link https://hopin.com/events/evergreen-international-hackfest-2022?code=R7fHd20cOcsFkNlh7hoGEZQbG |
| 08:34 |
RFrasur |
There was mention yesterday about an issue with B&T's FTP. Anyone know if that's an issue still? |
| 08:41 |
RFrasur |
Hmm, it appears to be. |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:43 |
miker |
should I be concerned that my "eeevil" karma is higher than my "miker" karma? |
| 08:46 |
mmorgan |
kmlussier++ |
| 08:47 |
|
mdriscoll joined #evergreen |
| 08:51 |
miker |
berick: I plan to start poking at the redisrf code, but wanted to follow up on the part that confused me most yesterday. you were saying the router would need to listen on multiple sockets, but I still can't see why. in xmpp, we need multiple sockets because the jid is the analog of a redis stream or list, but is /also/ the endpoint id of an xmpp session. in redis, the router would just have one "incoming" connection to the "local" redis server and |
| 08:51 |
miker |
it would xgroupread or blpop from all the lists/streams together, in one command. it would need to connect (perhaps persistently, perhaps transiently) to "foreign" redis servers, to throw messages at "foreign" lists/streams that have a listener (or drones directly!) behind them, but that's all during the processing loop for the message in hand and is all outgoing. |
| 08:57 |
miker |
(also, as a side note, because stream entries are each an order set of key/value pairs, using streams rather than lists would let us unwrap some of the message envelop to be natively redis. IOW, we could reduce a /lot/ of the de/re-serialization by putting things like request id, thread trace, originating sender coordinates, etc, outside the message blob) |
| 09:02 |
|
Dyrcona joined #evergreen |
| 09:04 |
Dyrcona |
@karma |
| 09:04 |
pinesol |
Dyrcona: Highest karma: "bshum" (2), "kmlussier" (2), "evergreen" (1), "community" (1), and "parts" (1). Lowest karma: "evergreen" (1), "community" (1), "parts" (1), "bshum" (2), and "kmlussier" (2). |
| 09:04 |
Dyrcona |
bshum++ kmlussier++ |
| 09:07 |
|
mantis1 joined #evergreen |
| 09:11 |
Dyrcona |
Good morning, #evergreen! |
| 09:12 |
|
Stompro joined #evergreen |
| 09:13 |
mmorgan |
Good morning! |
| 09:13 |
|
Stompro joined #evergreen |
| 09:22 |
|
rjackson_isl_hom joined #evergreen |
| 09:40 |
eby |
miker: / berick : going to test more next week but curious with your mention of setting workstation prefs as org unit settings. Does it act as a fall back default or as a forced preference? |
| 09:49 |
phasefx |
berick: do you want to talk SIP2M sometime today? I don't have an agenda, but we could determine/sanity-check next steps |
| 09:51 |
berick |
eby: it acts as fall back default. ignored in cases where a workstation setting value is already saved. |
| 09:52 |
berick |
best way to create is to save the value you want at a workstation, then copy the JSON from the value into the newly created org unit setting. |
| 09:52 |
eby |
Perfect thanks! |
| 09:52 |
eby |
berick++ |
| 09:52 |
mmorgan |
eby: But you could also remove the ws setting type (and ws settings) if you want to force it. |
| 09:52 |
berick |
mmorgan: yes, good call |
| 09:52 |
berick |
if you want to force it, remove the WS setting entirely |
| 09:53 |
mmorgan |
We have not done that, but have made wide use of the fallback! |
| 09:53 |
mmorgan |
berick++ |
| 09:53 |
berick |
phasefx: yes, happy to talk today |
| 09:54 |
phasefx |
berick++ I'll refresh my memory this morning and you can poke me whenever you'd like after lunch? |
| 09:55 |
berick |
+1 |
| 09:55 |
Stompro |
eby, I started a bug on documenting the workstation settings/org unit stuff that may be useful to you - https://bugs.launchpad.net/evergreen/+bug/1843454 |
| 09:55 |
pinesol |
Launchpad bug 1843454 in Evergreen "Docs: Default/Read Only Print Template Options" [Undecided,New] |
| 09:57 |
mmorgan |
Stompro++ |
| 09:57 |
berick |
Stompro++ |
| 09:58 |
|
jvwoolf joined #evergreen |
| 09:59 |
Dyrcona |
@decide local git or virtual machine git |
| 09:59 |
pinesol |
Dyrcona: go with local git |
| 10:07 |
* Dyrcona |
wonders if we should add some instrumentation to pingest.pl (and possibly drop the .pl extension). |
| 10:16 |
Dyrcona |
Hmm. I guess rebasing from master to rel_3_7 is not a good idea. |
| 10:18 |
miker |
Dyrcona: do I feel my ears burning? ;) (if you're looking at what I think you're looking at, if you can test closer to master I think you'll have more success) |
| 10:18 |
Dyrcona |
Remote syntax in git can be annoying: orign/rel_3_7 for one command and origin[space]rel_3_7 for another. |
| 10:19 |
Dyrcona |
miker: I am. I plan to start testing with rel_3_7 today and an upgrade to rel_3_9 next week if that's OK. |
| 10:20 |
|
mdriscoll joined #evergreen |
| 10:20 |
Dyrcona |
I suppose the different syntax is what they call commitish (in the / case) and remote[space]branch in the latter. |
| 10:22 |
Dyrcona |
I should copy the database that I want to use so it won't get obliterated this weekend. |
| 10:23 |
* Dyrcona |
is tempted to test on Pg 14 since there was an update this morning... ;) |
| 10:43 |
miker |
Dyrcona: as far as order and timing goes, I'm just glad someone's looking at it, but just to note that deadlock+symspell branch was developed after 3.7 (recall, nocase browse) so starting with vanilla 3.8 or 3.9 (/not/ patched with this and then upgraded) may be less of a headache. I get that "with your data" testing isn't particularly feasible at scale for versions past what you're actually on, though. |
| 10:46 |
Dyrcona |
miker: Right. I previously made a 3.7 backport and only had had to change the db upgrade script. Looks the same still, but I'll see what happens. If it just blows up, I'll move to upgrading to 3.9 over the weekend. |
| 10:47 |
Dyrcona |
I'm going to compare the implementation of metabib.reingest_metabib_field_entries in the two db upgrades. I think we can delete the one from the WWW upgrade. |
| 10:51 |
Dyrcona |
Yeah, only difference is the check for reification. |
| 10:52 |
Dyrcona |
Barring any other surprises, I think it will work on 3.7 with just the same modifications as before. |
| 11:01 |
Dyrcona |
Downgrading on a vm is also fun... |
| 11:07 |
miker |
right, if we take both commits, we just need the latest one |
| 11:07 |
|
jihpringle joined #evergreen |
| 11:07 |
miker |
downgrading? never 'eard of 'im. |
| 11:11 |
csharp_ |
downgrader? I never even met her! |
| 11:11 |
Dyrcona |
:) |
| 11:11 |
* csharp_ |
can't hackfest today - tied up in holds issue |
| 11:11 |
Dyrcona |
:( |
| 11:11 |
csharp_ |
frakking age protection |
| 11:11 |
Dyrcona |
csharp_++ |
| 11:11 |
csharp_ |
it's for the birds |
| 11:12 |
csharp_ |
a workaround for some nimrod in the early PINES planning meetings who said he was never going to buy new items again because other libraries could buy them for them |
| 11:12 |
* Dyrcona |
is too lazy to build a new vm, so rm -rf /openils/*, and reinstall OpenSRF and older version of Evergreen. Also had to rm node, but I wrote a script for that some years ago. :) |
| 11:12 |
csharp_ |
libraries said "oh yeah?" - thus age protection |
| 11:13 |
berick |
hold my beer |
| 11:13 |
Dyrcona |
Age hold protection is a decent feature IMHO. It just doesn't always do what the users expect. |
| 11:14 |
* Dyrcona |
takes a short walk while the database is copied... |
| 11:14 |
mmorgan |
csharp_: Trying to understand the issue. Age protection expires at some point ... |
| 11:14 |
csharp_ |
it's fine, I'm just mad that it's failing for some reason |
| 11:14 |
csharp_ |
some stupid HUMAN did something somewhere that broke stuff |
| 11:14 |
* csharp_ |
may be the human in question :-) |
| 11:15 |
berick |
spiderman <-> spiderman |
| 11:15 |
mmorgan |
Failing to protect? |
| 11:15 |
berick |
irc_memes-- |
| 11:15 |
mmorgan |
Or being over-protective? |
| 11:16 |
Dyrcona |
@blame Humans |
| 11:16 |
pinesol |
Dyrcona: Humans HAXORED Dyrcona's SERVERZ!!!! |
| 11:16 |
csharp_ |
berick++ |
| 11:16 |
miker |
csharp_: I don't recall hearing that age protection story, but I don't doubt it. basically why public bookbags took so long to happen :) |
| 11:16 |
mmorgan |
Darn humans :-/ |
| 11:17 |
csharp_ |
my solution to the problem with a consortium like PINES is to have a consortial agreement to purchase or rent pop materials with a formula in place for fair distribution |
| 11:17 |
csharp_ |
during the first 12 months of life, those items are consortium owned |
| 11:18 |
csharp_ |
after which the copies are fairly distributed to the libraries to be "owned" by them outright (unless they're rentals) |
| 11:19 |
csharp_ |
miker: yeah - I think this was in the 1998-1999 timeframe if my understanding is correct |
| 11:19 |
csharp_ |
the director in question is long dead, I believe, but his ghost haunts us all |
| 11:20 |
csharp_ |
@blame add $who - what a bunch a bastards! |
| 11:20 |
pinesol |
csharp_: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
| 11:20 |
csharp_ |
@blame add $who - what a bunch a bastards! |
| 11:20 |
pinesol |
csharp_: The operation succeeded. Blame #32 added. |
| 11:21 |
mmorgan |
csharp_: So when the copies are distributed to the libraries, do they create brand new item records for them? |
| 11:22 |
csharp_ |
mmorgan: never got to that level of detail in my fantasy :-) |
| 11:22 |
csharp_ |
presumably they would already be cataloged and could just change owners |
| 11:24 |
mmorgan |
Right. That being the case, I'm not seeing why age protection would be problematic. |
| 11:25 |
csharp_ |
it would rid libraries of the need to think of *their* new items as having particular value |
| 11:25 |
csharp_ |
pop materials pretty much never land on the shelf for the first 6 months of life anyway, so why complicate things? |
| 11:26 |
csharp_ |
"at least they are never here because *our* patrons have them" |
| 11:27 |
csharp_ |
plus, my assumption would be a potential cost savings by purchasing/renting at scale |
| 11:27 |
csharp_ |
as Michael Scott would say win-win-win |
| 11:28 |
csharp_ |
this is all in theory, btw - it's never gone beyond my crackpot scheming :-) |
| 11:50 |
rhamby |
Isn't crackpot scheming a wird al cover band? |
| 11:51 |
berick |
i really hope so |
| 11:51 |
|
rjackson_isl_hom joined #evergreen |
| 11:55 |
berick |
@ana crackpot scheming cover band |
| 11:55 |
pinesol |
berick: Pong mock scratched vibrance |
| 11:56 |
berick |
@band add Scratched Vibrance |
| 11:56 |
pinesol |
berick: Band 'Scratched Vibrance' added to list |
| 12:00 |
Dyrcona |
csharp_: Make it a floating collection and no one has to mess with ownership. |
| 12:00 |
Dyrcona |
Also, good luck with ridding "libraries of the need to think of *their* new items as having particular value" |
| 12:11 |
csharp_ |
@band add [ana [someone]] |
| 12:11 |
pinesol |
csharp_: Band 'Im surly jar' added to list |
| 12:16 |
Dyrcona |
That's my band: Surly Jar... :) |
| 12:18 |
berick |
heh |
| 12:29 |
jamin |
We definitely appreciate age protection... allowed us to get rid of a lot of manual "denewing" processes and circ rules. Whereby members could hold on to stuff locally at first, then share. (Without which we wouldn't have been able to start sharing at all.) |
| 12:32 |
Dyrcona |
miker: I'm ready to start a timed pingest on my 3.7 production data without doing the symspell set up first. Last time I tried that it started out being relatively quick, then slowed down as more records were ingested. |
| 12:33 |
Dyrcona |
And, I will use the --delay-symspell option. |
| 12:53 |
|
jihpringle joined #evergreen |
| 13:13 |
|
mdriscoll joined #evergreen |
| 13:15 |
pinesol |
News from commits: Docs: fix display error <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=45a4a822ca16605111b225888c848134e64fb348> |
| 13:16 |
JBoyer |
I'm also basically out of pocket / on the bench / choose your own favorite game / sport related euphemism for unavailable for any real hacking at the fest. Additionally, if anyone wanted to take the reins / read the agenda for the dev meeting this afternoon I would be happy to just listen in and pop in should I have something worth saying. |
| 13:19 |
miker |
Dyrcona: huzzah! with that option it /should/ be as fast as before (insert-only into the unlogged table) and then at the end there'll be a pause while it shoves the changes in, in one go |
| 13:22 |
Dyrcona |
miker: We'll see. |
| 13:22 |
Dyrcona |
I also just tested a 3.7.3 to 3.9 db upgrade that I prepared for next week, and I got this error: psql:3.7.3-3.9-upgrade-db.sql:3509: ERROR: cannot drop type search.search_result because other objects depend on it |
| 13:22 |
Dyrcona |
DETAIL: function search.query_parser_fts(integer,integer,text,integer[],integer[],integer,integer,integer,boolean,boolean,integer) depends on type search.search_result |
| 13:22 |
Dyrcona |
I wonder if we have something old or custom hanging around? |
| 13:23 |
Dyrcona |
The suggestion in the error report was to use drop cascade. |
| 13:24 |
Dyrcona |
Looks like we won't be needing it. |
| 13:27 |
jeffdavis |
We have two versions of search.query_parser_fts in our environment and I've had to manually drop the second one for the upgrade scripts to work in testing. |
| 13:27 |
jeffdavis |
So yeah, probably an old version of that function sticking around on ancient EG installs. |
| 13:30 |
Dyrcona |
jeffdavis: Thanks. That's what this looks like. |
| 13:30 |
Dyrcona |
I'm using cascade on the type drop, and that appears to work. |
| 13:32 |
Dyrcona |
It's fun running upgrades over multiple version. :) |
| 13:32 |
|
smorrison joined #evergreen |
| 14:18 |
RFrasur |
@mmorgan @Dyrcona @JBoyer @miker @rhamby @phasefx @csharp_ @berick (yes, picking @'s that I saw and know stuff) 1. What does "pre-fetch" holds mean? and, 2. Is Evergreen's FTP hardcoded as passive? |
| 14:18 |
pinesol |
RFrasur: Have you run autogen.sh? |
| 14:19 |
RFrasur |
@pinesol - No. I can't. |
| 14:19 |
pinesol |
RFrasur: Beyond here be dragons. |
| 14:20 |
berick |
RFrasur: if the number of holds exceeds the page size of the grid, you can chose to fetch only the visible holds or all the holds |
| 14:20 |
berick |
the latter being prefetch |
| 14:20 |
berick |
this can make other operations quicker after the fetching is done |
| 14:20 |
berick |
helpful if you know you want the whole list (e.g. for printing) |
| 14:20 |
berick |
less helpful if you have 1,000 holds |
| 14:21 |
RFrasur |
Oh, so if you wanted to retarget all holds, you'd have that selected? |
| 14:21 |
RFrasur |
If there were more than 100? |
| 14:21 |
RFrasur |
(in holdings view, that is) |
| 14:22 |
* csharp_ |
just discovered ef in psql and mind is blown |
| 14:22 |
csharp_ |
been copying/pasting/screwing around with whitespace forever |
| 14:24 |
rhamby |
*nods* \ef is super useful |
| 14:24 |
berick |
RFrasur: i'd have to look. sometimes the UI will fetch the hold IDs, but not the holds themselves, and perform actions just using the IDs |
| 14:24 |
berick |
retarget only requires the hold id, for example |
| 14:25 |
berick |
in either case, the functionality is the same, it's just a question of when (and if) you fetch all the data |
| 14:25 |
RFrasur |
berick++ |
| 14:25 |
RFrasur |
Useful no matter. Thank you. |
| 14:27 |
miker |
RFrasur: re FTP, you mean for EDI? it's not hard coded afaict, but passive is recommended because firewalls |
| 14:29 |
RFrasur |
miker, yes for EDI. Just off the phone with B&T about EDI orders failing with their FTP. They recently changed IPs cuz of this and that. We use their host name rather than the IP anyway, but apparently only active FTP is working for them right now. The person I talked with was under the impression that Evergreen FTP is set up as strictly passive. He used the word "hardcoded." |
| 14:30 |
miker |
well, it's configurable, but on the server. not through the staff interface (AFAIK) |
| 14:31 |
RFrasur |
Def not through the interface...(now I'm going to go verify that I didn't miss a tick box somewhere). |
| 14:31 |
RFrasur |
miker++ |
| 14:33 |
RFrasur |
newp. No tick box (LP ticket? maybe in a second or 360). |
| 14:35 |
miker |
yeah, it's definitely only controlled by an environment variable when the fetcher and pusher are run. if B&T are alone in needing active, then it will take a little work because each vendor account will need its own crontab line, I think |
| 14:35 |
miker |
definitely good to LP. should be able to control that at the remote_account level, I think. |
| 14:37 |
RFrasur |
They're working to fix it on B&T's end to allow for passive again (it was broken in their IP transfer somehow), but in the meantime....hmm. Maybe we just wait. So, a LP. |
| 14:38 |
JBoyer |
I think it's probably hard-coded for you RFrasur because I don't think active FTP won't work with your network. (It has been A Bit, so I'm not 100% certain) |
| 14:38 |
Dyrcona |
RFrasur: We've had issues with B&T for a couple of days. Stompro and I discussed it briefly yesterday. |
| 14:38 |
Dyrcona |
We use PASV. |
| 14:38 |
RFrasur |
JBoyer, I think you're correct in that. Dyrcona, it was your discussion yesterday that prompted me to call them. |
| 14:39 |
Dyrcona |
We set FTP_PASSIVE in the crontab. |
| 14:40 |
RFrasur |
Sigh. So, we wait for them to fix things. |
| 14:40 |
Dyrcona |
Yeah. It's broken on their side. |
| 14:40 |
RFrasur |
Well, Dyrcona++ JBoyer++ miker++ thank you. |
| 14:41 |
Dyrcona |
There are firewall modules that proxy FTP so you can use active mode, but I don't have control of the CWMARS firewall. |
| 14:41 |
JBoyer |
Yeah, Active FTP is an archeological curiosity in 2022, not a viable protocol for most hosts. |
| 14:41 |
RFrasur |
Yeah, and our environment is kinda convoluted. |
| 14:41 |
Dyrcona |
I agree with Stompro that it would be better if B&T supported SFTP or SCP. |
| 14:42 |
Dyrcona |
JBoyer: In my experience, it is still 1995 at most library vendors as far as the Internet is concerned. |
| 14:42 |
RFrasur |
JBoyer, it was my momentary hope that we could switch to active until they got passive fixed so that the 8 POs languishing could go through. Which isn't too bad right now. |
| 14:43 |
Dyrcona |
"We set it up in 1993, and it works. Why should we change it?" |
| 14:43 |
RFrasur |
I did learn (?) that Follett and B&T are divested of one another though. That's...something. (The impetus for the IP change) |
| 14:44 |
RFrasur |
The guy on the phone was chatty. |
| 14:45 |
pinesol |
News from commits: lp1942647 Provide Warning when deleting Term linked to Courses <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b36ac41bd10b2a79849f1d1249442088ee77804b> |
| 14:45 |
|
collum joined #evergreen |
| 14:45 |
miker |
that seems like a short union ... but in pandemic time who knows? oh, 2016, much longer than I thought |
| 14:46 |
RFrasur |
lol, miker, gettin' old over there? :D |
| 14:46 |
RFrasur |
(it was short, but why miss an opportunity to make an old joke?) |
| 14:46 |
miker |
I haven't had a birthday yet. it's only March 859th, 2020 |
| 14:47 |
RFrasur |
miker++ |
| 14:48 |
Dyrcona |
miker++ |
| 14:48 |
RFrasur |
I want to add to that joke (buh dum dum), but would have to reverse engineer to much with my OWN aging hardware. |
| 14:48 |
Dyrcona |
RFrasur++ |
| 14:49 |
* Dyrcona |
sympathizes with Marvin the Android: I have a pain in all of the diodes down the left side of my body. |
| 14:49 |
mmorgan |
Dyrcona++ |
| 14:49 |
RFrasur |
Dyrcona++ |
| 14:50 |
|
mdriscoll joined #evergreen |
| 14:51 |
miker |
RFrasur++ |
| 14:59 |
|
shulabear joined #evergreen |
| 15:09 |
csharp_ |
Dyrcona: did you have to rejigger JSON as text datatype stuff on PG 10? - our age protection not working was happening because "true" != true |
| 15:10 |
csharp_ |
the setting value is literally "true" and the hold request permit function is comparing it with 'true' |
| 15:10 |
csharp_ |
my dirty fix is trimming the quotes, but I feel like there hasta be a better way |
| 15:11 |
csharp_ |
(I know the dev meeting is in progress but I can't attend - have to pick up my daughter from her day program) |
| 15:17 |
miker |
csharp_: ah! that's a library setting editor bug! I think I fixed that recently. sec |
| 15:21 |
csharp_ |
miker++ |
| 15:26 |
Dyrcona |
csharp_: We haven't noticed, but I'm 99% all of our JSON booleans are true without quotes. |
| 15:27 |
|
tlittle joined #evergreen |
| 15:29 |
|
jihpringle joined #evergreen |
| 15:55 |
Bmagic |
JBoyer++ # Dev meeting |
| 15:56 |
tlittle |
RFrasur Any chance you'd be willing to update the acq listserv that B&T FTP has some issues right now? I got a report today that we weren't getting invoices from them and didn't realize it was a widespread issue until I saw you mention it |
| 15:56 |
RFrasur |
Yep, I'd be glad to. |
| 15:57 |
tlittle |
Thank you! |
| 15:59 |
tlittle |
RFrasur++ |
| 16:07 |
RFrasur |
tlittle, there are gaps in what I sent, but hopefully it's mostly comprehensible. |
| 16:08 |
tlittle |
No, that's wonderful! I appreciate it. Good call on adding the bit about seeing the PUT errors--I'm going to back through our EDI messages for the past couple of days to see how many we've got affected |
| 16:09 |
RFrasur |
And shout out to the "new" PO search, lol. Very easy to pinpoint things. It'd be even easier if our libraries used standard providers, but no need to get too crazy. |
| 16:09 |
tlittle |
I have two reports that run everyday to let me know if there are errors on EDI invoices or with ORDERS/ORDRSP messages but I've been lazy this week because of the conference and hadn't been looking. Oops |
| 16:10 |
RFrasur |
Eh. Not the end of the world. There's little to be done at this point anyway. "Wait until [they] fix(es) it." |
| 16:10 |
tlittle |
True facts |
| 16:11 |
Dyrcona |
Here's the script that I use to stamp versions in files when making local branches, it could be useful for the release process: https://gist.github.com/Dyrcona/933dd1a2e9035fdc48162dbcfcb51a2d |
| 16:23 |
|
Stompro joined #evergreen |
| 16:23 |
|
Guest5426 joined #evergreen |
| 17:10 |
|
jvwoolf left #evergreen |
| 17:17 |
|
mmorgan left #evergreen |
| 17:18 |
Bmagic |
I'm logged into our WP Evergreen website for the first time. Who's in charge? |
| 17:31 |
Bmagic |
I volunteered to take a stab at organizing our conference prestation in a searchable "catalog". My natural inclination is to integrate that into our website. But WP is old... |
| 17:31 |
Bmagic |
presentations* |
| 17:32 |
Bmagic |
my keyboard is dropping keystrokes... not sure what's going on but it's been doing that lately |
