| Time |
Nick |
Message |
| 00:50 |
|
dcook joined #evergreen |
| 07:13 |
|
akilsdonk joined #evergreen |
| 08:05 |
|
ningalls joined #evergreen |
| 08:16 |
|
rjackson-isl joined #evergreen |
| 08:19 |
|
mrpeters joined #evergreen |
| 08:55 |
|
finnx joined #evergreen |
| 08:57 |
|
finnx joined #evergreen |
| 08:58 |
|
finnx joined #evergreen |
| 09:00 |
|
finnx joined #evergreen |
| 09:00 |
|
finnx joined #evergreen |
| 09:02 |
|
Dyrcona joined #evergreen |
| 09:02 |
|
finnx joined #evergreen |
| 09:03 |
|
finnx joined #evergreen |
| 09:04 |
|
finnx joined #evergreen |
| 09:05 |
|
kbeswick joined #evergreen |
| 09:05 |
|
finnx joined #evergreen |
| 09:06 |
|
finnx joined #evergreen |
| 09:07 |
|
finnx joined #evergreen |
| 09:07 |
kmlussier |
@later tell remingtron I had used the bitesize-doc tag so that doc bitesize reports didn't intermingle with small bug reports, particularly when we point new developers to the bitesize tag to find small bugs to help get them started. |
| 09:07 |
pinesol_green |
kmlussier: The operation succeeded. |
| 09:08 |
|
finnx joined #evergreen |
| 09:08 |
kmlussier |
@later tell remingtron If we think it's okay to use bitesize for both, then we should probably update http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:lp_docs. |
| 09:08 |
pinesol_green |
kmlussier: The operation succeeded. |
| 09:09 |
|
finnx joined #evergreen |
| 09:10 |
|
finnx joined #evergreen |
| 09:12 |
remingtron |
kmlussier: sorry or changing that without asking. It looked like we had many bugs tagged both "documentation" and "bitesize", and only one using "bitesize-doc", so I judged based on that. |
| 09:12 |
remingtron |
but I think you are right, that it's helpful to separate them for the sake of new devs |
| 09:12 |
remingtron |
so they don't get confused with doc bugs |
| 09:12 |
kmlussier |
Ah, I see. Yes, I probably didn't update the old ones after writing up the guidelines. |
| 09:12 |
kmlussier |
I'm a little scattered these days. :) |
| 09:13 |
remingtron |
not a problem. would you like to update the bugs to bitesize-docs, or shall I? |
| 09:13 |
kmlussier |
remingtron: I can do it. Thanks! |
| 09:13 |
remingtron |
thank you. kmlussier++ |
| 09:14 |
kmlussier |
remingtron++ # doc wrangling |
| 09:15 |
jeff |
i was going to suggest searching based on both documentation and bitesize, but of course there doesn't seem to be a way to search on bitesize and NOT documentation, so nevermind that. |
| 09:16 |
kmlussier |
jeff: Good thought, though! :) |
| 09:25 |
|
mmorgan joined #evergreen |
| 09:29 |
kmlussier |
bshum: What can I do to make the bitesize-doc tag appear as a suggested tag in Launchpad? |
| 09:29 |
kmlussier |
Or is that something only people with special powers can do? |
| 09:29 |
bshum |
kmlussier: Special powers, yes |
| 09:29 |
bshum |
But basically we can edit "official tags" |
| 09:29 |
bshum |
And that makes them suggestions |
| 09:30 |
|
hopkinsju joined #evergreen |
| 09:30 |
* kmlussier |
feels so powerless now. |
| 09:30 |
bshum |
That can quickly change |
| 09:31 |
bshum |
Though for note |
| 09:31 |
bshum |
The other day, folks were having problems with tagging with the dash in between words |
| 09:31 |
bshum |
So "bitesize-doc" might not be a good thing. For search reasons. |
| 09:33 |
kmlussier |
Huh, I didn't have any trouble. |
| 09:34 |
bshum |
Well, hbrennan had notable issues while Dyrcona didn't |
| 09:34 |
bshum |
So I think we wondered if it was because some of us have more LP powers or something |
| 09:34 |
bshum |
Either way, my general recommendation based on that incident was to avoid use of dashes in bug tagging. |
| 09:35 |
Dyrcona |
I don't thinks tags are searched in regular search anyway. |
| 09:35 |
bshum |
Not as such. I think you have to use advanced search regardless. |
| 09:35 |
Dyrcona |
In my unscientific trial, I had to go to advanced search to search on a tag. |
| 09:35 |
bshum |
Or click on the official tags to the right of the main bug window |
| 09:37 |
* bshum |
pokes at this later. Has to go dig himself out of snow first. |
| 09:37 |
* mrpeters |
feels your pain bshum --- we had 14 inches of NEW snow to dig out of on monday...on top of about 8 we already had |
| 09:37 |
* mrpeters |
hopes you have a snowblower!!! |
| 09:43 |
jeff |
there was a run on snowblowers in town, and my vehicle isn't suitable for a plow, but i did get a great deal on a used Zamboni. driveway's a little slippery now, but flat as can be! |
| 09:45 |
mrpeters |
hahahaha |
| 09:45 |
mrpeters |
i bought one in june |
| 09:48 |
Dyrcona |
jeff++ |
| 09:48 |
Dyrcona |
mrpeters: A Zamboni? |
| 09:49 |
mrpeters |
lol no a snowblower |
| 09:49 |
mrpeters |
i bought an indycar chassis in december :P |
| 09:50 |
Dyrcona |
I saw an old, light blue Desoto for sale a couple of years and was very sorely tempted to buy it and restore it. |
| 09:50 |
Dyrcona |
Delbert McClinton fans will know why. :) |
| 09:50 |
Dyrcona |
...years [ago]... |
| 09:50 |
mrpeters |
http://imgur.com/u85C02N |
| 09:51 |
mrpeters |
http://imgur.com/JUxsg84 |
| 09:51 |
Dyrcona |
Stupid brain.... |
| 09:51 |
mrpeters |
someday this will be restored.... :) |
| 09:51 |
Dyrcona |
Cool. |
| 09:51 |
mrpeters |
ive got the biggest chunk outside of the engine |
| 10:03 |
|
gsams joined #evergreen |
| 10:07 |
|
akilsdonk_ joined #evergreen |
| 10:10 |
|
akilsdonk joined #evergreen |
| 10:31 |
ningalls |
turn that into your iracing seat |
| 10:32 |
ningalls |
drop in a G27 and call it a day mrpeters |
| 10:37 |
jeff |
heh. 99 minutes later, jeff realizes he didn't createdb with the proper encoding. |
| 10:37 |
jeff |
pg_restore: [archiver (db)] could not execute query: ERROR: Unicode escape values cannot be used for code point values above 007F when the server encoding is not UTF8 at or near "E'\u2021" |
| 10:48 |
|
cjohnson joined #evergreen |
| 10:52 |
kmlussier |
OK, so in reading back, hbrennan's problem was in adding the hyphen for the tag? I guess we need to use something else then. I'll have to give more thought to a good alternative a little later. |
| 10:52 |
* kmlussier |
uses the advanced search tag search all the time. |
| 10:55 |
kmlussier |
Now that the hyphenated tag is a suggested tag that people can select, I wonder if it will continue to be a problem. |
| 10:55 |
* kmlussier |
should ask hbrennan to try it the next time she's here. |
| 11:10 |
|
finnx joined #evergreen |
| 11:11 |
|
finnx joined #evergreen |
| 11:12 |
|
finnx joined #evergreen |
| 11:12 |
|
finnx joined #evergreen |
| 11:13 |
bshum |
kmlussier: The other thing I wonder is maybe if we created pre-set advanced search LP links to specific things. |
| 11:13 |
bshum |
And then give those links to others as pathfinders to locate specific criteria of bugs |
| 11:13 |
kmlussier |
bshum: Yes, the pre-set links were my plan. |
| 11:13 |
bshum |
Not that we don't all hate LP search enough anyways, but maybe if we have searches that do some of what we want, we should just start to share those. |
| 11:14 |
* kmlussier |
has lots of plans. |
| 11:14 |
|
finnx joined #evergreen |
| 11:14 |
kmlussier |
That is, my plan for a more user-friendly entry point to see the doc needs that were posted to Launchpad. |
| 11:15 |
|
finnx joined #evergreen |
| 11:16 |
|
yboston joined #evergreen |
| 11:16 |
|
finnx joined #evergreen |
| 11:17 |
|
finnx joined #evergreen |
| 11:18 |
|
finnx joined #evergreen |
| 11:19 |
|
finnx joined #evergreen |
| 11:20 |
|
finnx joined #evergreen |
| 11:22 |
|
finnx joined #evergreen |
| 11:23 |
jeff |
finnx: once your connection to irc has stabilized, please change your nick and come back to ask that the ban be removed. |
| 11:23 |
jeff |
drat. |
| 11:23 |
jeff |
should have had that queued up. :-) |
| 11:24 |
bshum |
Heh |
| 11:40 |
csharp |
jeff++ |
| 12:03 |
wjr |
another reason why irccloud is great: repeated join/parts are presented as a single line :) |
| 12:35 |
|
RoganH joined #evergreen |
| 12:39 |
|
Shae joined #evergreen |
| 12:58 |
|
j_scott joined #evergreen |
| 13:01 |
|
DPearl joined #evergreen |
| 13:02 |
* berick |
selfishly waits for someone else to chair the meeting |
| 13:03 |
|
mrpeters joined #evergreen |
| 13:07 |
* kmlussier |
almost forgot about the meeting, but I really can't chair today. |
| 13:08 |
* dbwells |
is finishing something time sensitive, but can chair in 2 or 3 minutes if nobody else does |
| 13:08 |
bshum |
I'll get us started I guess |
| 13:08 |
kmlussier |
bshum++ |
| 13:08 |
bshum |
If I can remember how to use the meetbot :) |
| 13:08 |
kmlussier |
IIRC, somebody wrote up this very nice guide to using meetbot. |
| 13:08 |
bshum |
Haha |
| 13:09 |
bshum |
#startmeeting 2014-01-10 - Developer Meeting |
| 13:09 |
pinesol_green |
Meeting started Fri Jan 10 13:09:20 2014 US/Eastern. The chair is bshum. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 13:09 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 13:09 |
pinesol_green |
The meeting name has been set to '2014_01_10___developer_meeting' |
| 13:09 |
bshum |
#link Agenda: http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-01-10 |
| 13:09 |
bshum |
#topic Introductions |
| 13:09 |
bshum |
#info bshum = Ben Shum, Bibliomation |
| 13:09 |
gmcharlt |
#info gmcharlt = Galen Charlton, ESI |
| 13:10 |
Dyrcona |
#info Dyrcona = Jason Stephenson, MVLC |
| 13:10 |
jeff |
#info jeff = Jeff Godin, Traverse Area District Library (TADL) |
| 13:10 |
dbs |
#info dbs = Dan Scott, Conifer |
| 13:10 |
DPearl |
#info DPearl = Dan Pearl, C/W MARS |
| 13:10 |
senator |
#info senator = Lebbeous Fogle-Weekley, ESI |
| 13:10 |
RoganH |
#info RoganH = Rogan Hamby, SCLENDS |
| 13:10 |
ldwhalen |
#info = Liam Whalen, Sitka |
| 13:11 |
|
mcooper joined #evergreen |
| 13:11 |
eeevil |
#info eeevil = Mike Rylander, ESI |
| 13:11 |
berick |
#info berick Bill Erickson ESI |
| 13:11 |
kmlussier |
#info kmlussier = Kathy Lussier, MassLNC |
| 13:12 |
bshum |
Okay, others feel free to introduce yourselves as you arrive, we're going to continue with the meeting. |
| 13:12 |
bshum |
#topic Past action items |
| 13:12 |
bshum |
I'm assuming all four of those need to be deferred. |
| 13:12 |
bshum |
Since I haven't seen movement on them yet. (mine included :( |
| 13:12 |
dbwells |
#info dbwells = Dan Wells, Calvin College |
| 13:13 |
eeevil |
bshum: well, I think dbs has added some pgtap info |
| 13:13 |
bshum |
Oh cool |
| 13:13 |
bshum |
Do you have a link to that for the ntoes? |
| 13:13 |
bshum |
*notes |
| 13:13 |
eeevil |
I'll find it |
| 13:13 |
bshum |
#action bshum to summarize bug tracking based on feedback from developers |
| 13:13 |
|
jihpringle_ joined #evergreen |
| 13:13 |
bshum |
I'm putting down deferred actions as actual actions for the notes |
| 13:14 |
dbs |
Think it's a README in src/sql/PG/t IIRC |
| 13:14 |
bshum |
gmcharlt: OpenSRF 2.3-beta? |
| 13:14 |
gmcharlt |
bshum: a couple mroe useful patches have come in, but now that those are ready, and more importantly, now that it's after the holidays, I'll cut next week |
| 13:14 |
bshum |
Cool, thanks |
| 13:15 |
bshum |
#action gmcharlt to cut OpenSRF 2.3-beta next week |
| 13:15 |
dbs |
eeevil: Oh, that README is bound up in a branch with the Encode.pm fixes |
| 13:15 |
eeevil |
dbs: ah, well, that's a one-liner for me ... |
| 13:15 |
eeevil |
ah! |
| 13:15 |
dbs |
(Because I added more tests for the Encode stuff) |
| 13:15 |
eeevil |
dbs++ |
| 13:15 |
bshum |
Ah, dbs++ |
| 13:15 |
dbs |
If we could merge that, we'd fix Fedora and get docs too.. *ahem* :) |
| 13:15 |
bshum |
Can I mark an action item for someone (maybe eeevil to check that in?) |
| 13:16 |
bshum |
#action eeevil to publish detailed plan about freezing baseline schemas between EG releases and using deprecates/supersedes in database upgrade scripts. This will go on the mailing list and the thread should structure further discussion of pros and cons of eeevil's plan. |
| 13:16 |
dbs |
#info branch with pgTAP tests and Encode fixes is in https://bugs.launchpad.net/evergreen/+bug/1242999 |
| 13:16 |
pinesol_green |
Launchpad bug 1242999 in Evergreen "Encode.pm 2.54 breaks database functions (naco_normalize, maintain_control_numbers, others)" (affected: 1, heat: 10) [High,Confirmed] |
| 13:16 |
dbwells |
I intend to re-review and push the Encode.pm stuff later today, or Monday at the latest. |
| 13:16 |
dbs |
dbwells++ |
| 13:16 |
bshum |
Cool deal. |
| 13:17 |
bshum |
#action dbwells to review bug 1242999 |
| 13:17 |
bshum |
That's it for past items for the moment. |
| 13:17 |
dbwells |
yay, an action item :) |
| 13:17 |
berick |
heh |
| 13:18 |
bshum |
#topic OpenSRF releases |
| 13:18 |
bshum |
I think we already covered the next 2.3 stuff, but is there anything else in the stable side? |
| 13:18 |
eeevil |
see: above ;) |
| 13:18 |
bshum |
#info See above for OpenSRF 2.3 beta. |
| 13:19 |
eeevil |
gmcharlt: do you plan to merge the few outstanding opensrf pullrequests before 2.3-b? |
| 13:19 |
gmcharlt |
eeevil: yep |
| 13:19 |
eeevil |
rock |
| 13:19 |
dbs |
awzzzzome |
| 13:19 |
gmcharlt |
eeevil: no, roll! |
| 13:19 |
|
fgmnnblv joined #evergreen |
| 13:20 |
bshum |
Okay. |
| 13:20 |
bshum |
#topic Evergreen releases |
| 13:20 |
eeevil |
2.4.5 has been sitting in preview ... I guess we should make it live :) |
| 13:21 |
bshum |
For this, I think I'm going to take an action item to go untangle the 2.4.5 milestones since eeevil did manage to get 2.4.5 done before the holidays. |
| 13:21 |
eeevil |
I'll be cutting 2.4.6 next weds IIRC |
| 13:21 |
eeevil |
bshum++ |
| 13:21 |
bshum |
#action bshum to fix up the 2.4.5 and set 2.4.6 milestones in LP |
| 13:22 |
bshum |
#info eeevil plans to cut 2.4.6 next Wednesday (2014-01-15) for next monthly maintenance release. |
| 13:22 |
dbwells |
#info cutoff for targetting bugs for inclusion in 2.6.0-alpha is next Thursday (1/16) |
| 13:22 |
bshum |
I assume we'll get a 2.5.2 release at the same time. |
| 13:22 |
Dyrcona |
Did someone else take over 2.5 from dbwells? |
| 13:22 |
bshum |
Or, yeah |
| 13:23 |
Dyrcona |
It doesn't seem fair that he would do 2.6 and 2.5. |
| 13:24 |
dbwells |
2.5.2 will come next week as well. So, far, I will be doing it, and we'll see how it goes. |
| 13:24 |
berick |
dbwells: i pushed some fixes for make_release that will make the job %0.2 easier ;) |
| 13:25 |
dbwells |
berick: yes, thanks! |
| 13:25 |
eeevil |
berick: I'd call them a 7% improvement, personally |
| 13:25 |
Dyrcona |
dbwells: If you want help or someone else to take over, I could do it. |
| 13:25 |
eeevil |
(I need to kill --right-only, or fix my git) |
| 13:26 |
berick |
eeevil: heh, didn't want to brag, or anything |
| 13:27 |
dbwells |
berick: eeevil: there are still a couple more bugs in make_release which I have been pulling in, I'll try to get those branched and in a bug. I don't think they make anything easier, though, just a little more accurate |
| 13:27 |
eeevil |
dbwells: thanks muchly! |
| 13:27 |
dbwells |
small stuff :) |
| 13:28 |
dbs |
On 2.6 - I know a few people have taken a look at at bug # 1261939 (thanks bshum / kmlussier!), but I'm wondering if, as a relatively largeish feature, it has a chance of actually getting in 2.6 |
| 13:29 |
|
mcooper joined #evergreen |
| 13:29 |
* eeevil |
looks |
| 13:29 |
bshum |
So we're moving into newish business, so I'm changing topics |
| 13:29 |
bshum |
#info Dyrcona offers to dbwells help on 2.5 maintaining (follow up on this) |
| 13:29 |
bshum |
#topic Evergreen 2.6 discussions |
| 13:29 |
dbs |
bshum: sorry, I thought this was in the "Evergreen release" territory |
| 13:30 |
bshum |
That's okay, I'm just trying to organize thoughts for the bot. (I'm underprepared today) |
| 13:30 |
eeevil |
dbs: IMO, it should. |
| 13:30 |
kmlussier |
dbs: I would like to see it in 2.6 if possible. |
| 13:30 |
bshum |
bug 1261939 |
| 13:30 |
pinesol_green |
Launchpad bug 1261939 in Evergreen "Add per-library TPAC pages with schema.org structured data support" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1261939 |
| 13:30 |
bshum |
(cause I'm lazy |
| 13:30 |
bshum |
Ah okay |
| 13:30 |
bshum |
+1 for 2.6 |
| 13:31 |
Dyrcona |
+1 for 2.6 |
| 13:31 |
eeevil |
dbs: the first chunk of that branch is in master now, yes? |
| 13:31 |
dbs |
(bshum was tempting me into auto-including google maps beside the addresses, and I have code for most of that, but I'm leery about weighing down this branch) :) |
| 13:32 |
kmlussier |
dbs / bshum: That would be awesome! But maybe in a separate branch? |
| 13:32 |
dbs |
eeevil: first chunk = move sample aou data out of 950 into concerto + add more realistic aou sample data was a separate bug |
| 13:33 |
eeevil |
aye |
| 13:33 |
eeevil |
"earliest" |
| 13:34 |
dbwells |
dbs: there are still other big features incoming which may get in. The fact that your code is already ready means I think it should get into 2.6 AND you get a gold star. |
| 13:34 |
dbs |
kmlussier: yep, that's what I was thinking too. a nice-to-have but not necessary |
| 13:34 |
bshum |
"gold star"++ |
| 13:34 |
* dbs |
blushes |
| 13:35 |
dbs |
#action dbs will write up the release notes as promises in bug # 1261939 for per-library TPAC pages |
| 13:36 |
* dbwells |
starts planning the "Evergreenies" awards ceremony for the 2.6 release party |
| 13:36 |
bshum |
dbwells++ |
| 13:37 |
bshum |
dbwells: Was there anything else you would like to say about 2.6 development plans at this time? |
| 13:37 |
berick |
who's that coming down the green carpet? |
| 13:37 |
bshum |
An idea I just had is to put your ideal milestone dates into the Evergreen development calendar. |
| 13:37 |
bshum |
So that we have one more reminder of key events |
| 13:37 |
dbwells |
yes, I am just starting to get back into the LP side of things. |
| 13:37 |
dbs |
bshum++ |
| 13:38 |
dbwells |
I changed the 2.next tag to 2.6.0-alpha earlier today. |
| 13:38 |
bshum |
I'll take an action item to help do that. Or give dbwells access to the google calendar to set it himself. |
| 13:38 |
bshum |
(probably both actually) |
| 13:38 |
egbuilder |
build #470 of evergreen-master-debian-6.00-x86_64 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/470 |
| 13:38 |
dbwells |
bshum++ |
| 13:40 |
bshum |
#action bshum to set new calendar entries for 2.6 milestone events and give access to dbwells to dev calendar. |
| 13:40 |
bshum |
Okay, anything else before we move on? |
| 13:41 |
dbwells |
nothing from me |
| 13:41 |
bshum |
Okay. |
| 13:41 |
bshum |
Go forth and target things |
| 13:41 |
bshum |
Next up, more new business |
| 13:42 |
bshum |
#topic Technical feedback on staff client prototype |
| 13:42 |
|
rfrasur joined #evergreen |
| 13:42 |
bshum |
berick: floor is yours |
| 13:42 |
bshum |
(to give to others) |
| 13:42 |
berick |
yep, I'm wondering if there are any comments on the techincal bits, since feedback has been sparse so far. |
| 13:43 |
ldwhalen |
I am concerned about the speed of Angularjs on older machines. I am not sure if this is a valid concern because I have not done any testing. |
| 13:43 |
|
akilsdonk joined #evergreen |
| 13:44 |
berick |
ldwhalen: where does the concern come from? |
| 13:44 |
bshum |
#link Prototype wrap-up report: http://yeti.esilibrary.com/dev/pub/web-staff-report.html |
| 13:44 |
ldwhalen |
Angularjs is obviously doing a lot of work manipulating the DOM and passing information back and forth via the $scope object |
| 13:45 |
RoganH |
I have done very limited testing. I've done demos to get feedback from front line staff on our "spare" machine the front desk. |
| 13:45 |
RoganH |
It's about a five year old low end intel with 2 gigs of RAM. The demo at least ran very well on it. |
| 13:45 |
berick |
so, my usual spiel on angular is that if we weren't using it, we would be doing all the same stuff manually w/ our own code (assuming a dhtml ui). |
| 13:46 |
ldwhalen |
my concern is with a bad model and view implementation it might be slow. I am not concerned with the current prototype. |
| 13:46 |
berick |
so, i understandn the concern in general about js UIs on older machines, but i'd be surprised if angular was slower than any other js toolkit |
| 13:46 |
gmcharlt |
ldwhalen: that's a rather ... generalized concern |
| 13:46 |
gmcharlt |
anything can be too slow if coded badly |
| 13:46 |
ldwhalen |
I want to idenitfy if there is a limit to chainging models and views in one screen and how we might avoid |
| 13:46 |
dbs |
ldwhalen: Angular is extremely lean, as far as JavaScript frameworks go |
| 13:47 |
ldwhalen |
alright. I will go and test and come back if I have any concerns. |
| 13:48 |
dbs |
berick: is bootstrap 2 or 3 in use? (Yes, I have not dived into the prototype code yet) |
| 13:48 |
jeff |
ldwhalen++ |
| 13:48 |
berick |
ldwhalen: cool, testing very much appreicated |
| 13:48 |
jeff |
dbs: it appears to be 3.0.1 |
| 13:49 |
* dbs |
looked and confirmed that too |
| 13:49 |
Dyrcona |
My only question is: Are AngularJS and Bootstrap the final word on the staff client? |
| 13:49 |
dbs |
Good! |
| 13:49 |
Dyrcona |
That is, are these these the toolkits that will be used for the final version? |
| 13:49 |
berick |
Dyrcona: that's pretty much what I'm trying to answer here |
| 13:49 |
berick |
looking for some consensus |
| 13:50 |
Dyrcona |
I want to know before I invest a lot of time in learning them. I'm always up for learning something new, but my time is more limited than ever. |
| 13:50 |
dbs |
They seem like pretty solid choices from an adoption front at this point in time. Also reassured that Bill's prototype report didn't point out any horrifying deadends. |
| 13:51 |
dbwells |
I think they are both good choices based on widespread use. |
| 13:51 |
RoganH |
we have several strong arguments for, are there any dissenting opinions? |
| 13:51 |
ldwhalen |
Are we willing to consider native app development? |
| 13:51 |
Dyrcona |
I believe they are good choices from what I have read about them. I have no suggestions for anything different. |
| 13:51 |
berick |
ldwhalen: we've already passed that bridge at the hackaway |
| 13:51 |
ldwhalen |
ok |
| 13:52 |
dbs |
Boostrap 3 is notable because of partial support for IE 8 / 9 per http://getbootstrap.com/getting-started/#browsers |
| 13:52 |
RoganH |
If there are no alternatives proposed I think we should consider that consensus. |
| 13:52 |
RoganH |
Unless we want to form action committees to strategize or something else equally painful. |
| 13:52 |
berick |
dbs: note, however, the js in the prototype is not IE compatible |
| 13:52 |
dbwells |
dbs: are you saying notable that they support it at all, or notable for being partial? |
| 13:52 |
dbs |
berick: ah, that is good to note! |
| 13:53 |
dbs |
notable for being partial, i.e. set expectations for IE accordingly (see what I did there?) |
| 13:53 |
* Dyrcona |
sees lack of IE support as a good thing. |
| 13:53 |
* berick |
too |
| 13:53 |
* RoganH |
works at a library that officially offers no support for IE for our patrons. |
| 13:53 |
ldwhalen |
RoganH: I would add that as long as doing sensible MVC stuff with Angularjs is not too slow on older machiens |
| 13:54 |
jboyer-isl |
The only real benefit I see to that is that a non-default browser means you can have printer defaults more amenable to receipts. |
| 13:54 |
RoganH |
ldwhalen: I think we always have to leave the door open to re considering if we hit a land mine. |
| 13:54 |
dbs |
berick: your report made no mention of printing support; any thoughts on that? |
| 13:54 |
jboyer-isl |
(The non-IE support, that is_ |
| 13:54 |
dbwells |
berick: I think last I checked, you were using a third party integration of Angular and Bootstrap. Is that still true? |
| 13:54 |
ldwhalen |
I hope to rid myself of that concern with the testing |
| 13:54 |
jeff |
I understand that bootstrap 3.x is not backward compatible with bootstrap 2.x, and that the effort involved in porting from 2.x to 3.x can vary by site/app, but can be significant. Does bootstrap 3.x have a stated/expected lifespan / support lifecycle? |
| 13:55 |
berick |
dbs: it's covered more fully in the specs and original proposal: printing and offline storage will be a separate project |
| 13:55 |
berick |
dbwells: 3rd-party hosted, yes, that will have to change eventually, but it's easier for testing |
| 13:56 |
berick |
jeff: good question. |
| 13:56 |
dbwells |
berick: no, I mean the AngularUI stuff. I think that is a third party, right? |
| 13:56 |
berick |
dbwells: oh, yes, that is. |
| 13:56 |
rfrasur |
Is this a meeting or general discussion? |
| 13:56 |
berick |
i pulled that in to get bootstrap-via-angular support (no bootstrap.js or jquery required) |
| 13:56 |
dbs |
jeff: well, worst case scenario we just roll with Bootstrap 3 until we can address the technical debt, no? |
| 13:56 |
bshum |
rfrasur: dev meeting |
| 13:56 |
jeff |
rfrasur: discussion during the course of a meeting. :-) |
| 13:56 |
rfrasur |
k |
| 13:56 |
bshum |
And both |
| 13:57 |
* rfrasur |
shushes |
| 13:57 |
dbwells |
berick: Do you have any sense of how dependent we will be on that project? It seems like the weakest link, but I can't really judge how weak at this point. |
| 13:57 |
gmcharlt |
dbs: and hope that the Bootstrap team got enough flack that they think more carefully about backwards compatiblity issues when they bump up to 4 |
| 13:58 |
dbs |
gmcharlt++ |
| 13:58 |
Dyrcona |
You guys are talking like it is commercial software or something.... ;) |
| 13:58 |
berick |
dbwells: agreed it is the weekest link. right now, we're only using the bootstrap bits. what we use for other UI components is yet to be determined. |
| 13:58 |
berick |
i'd like to use it, since we have it, but it is young |
| 13:58 |
berick |
so, i'm open to discussion on that |
| 13:59 |
berick |
dbs: gmcharlt: my thoughts exactly |
| 13:59 |
berick |
i'm assuming keeping up with bootstrap versions will be easier than rolling our own |
| 13:59 |
bshum |
Cool, so any other thoughts for berick before we move on? (feel free to continue discussions post-meeting, via lists, etc.) |
| 14:00 |
jeff |
berick++ |
| 14:00 |
bshum |
Also, berick++ and thanks to everyone who contributed to the prototype's creation |
| 14:00 |
RoganH |
berick++ |
| 14:00 |
berick |
(though we clearly need to make version tracking a high priority) |
| 14:00 |
gmcharlt |
berick: certainly in the long run; we've tasted the bitterness of staying stuck on older library versions |
| 14:00 |
berick |
yes, thanks to all the contributers! |
| 14:00 |
dbwells |
berick++ |
| 14:00 |
gmcharlt |
berick++ |
| 14:00 |
bshum |
Okay |
| 14:00 |
ldwhalen |
I know I am being very criticl, but I am also concerned with the use of TT2 wihtin an Angularjs app. |
| 14:01 |
ldwhalen |
and berick++ |
| 14:01 |
jboyer-isl |
ldwhalen: as far as tt2 is concerned, that's all server side, no? |
| 14:01 |
dbs |
ldwhalen: what is the specific concern? |
| 14:02 |
ldwhalen |
yes, but there are plans for server side compilation of Angularjs apps and I am worried that having TT2 in the app may prevent us from capitalizing on benefits that might be offered there |
| 14:02 |
ldwhalen |
As well, I think it complicates the conceptual nature of the MVC within Angularjs |
| 14:03 |
bshum |
ldwhalen: For consideration, I think it'd be great if you could write up your concerns as a reply on the list to berick's thread asking for technical feedback. |
| 14:03 |
jboyer-isl |
I see. |
| 14:03 |
ldwhalen |
bshum: I will do that |
| 14:03 |
eeevil |
ldwhalen: we need a templating system to support local customization ... we know tt2, and it's both fast and already integrated ... |
| 14:03 |
bshum |
ldwhalen: Thanks. |
| 14:04 |
bshum |
So last topic on the agenda: |
| 14:04 |
berick |
the browser gets a page that angular drives, how it gets that page has no impact on angular / mvc |
| 14:04 |
bshum |
#topic OS support |
| 14:04 |
berick |
bshum: one sec! |
| 14:04 |
berick |
i have a final question in my talking points |
| 14:04 |
bshum |
berick: Okay :) |
| 14:04 |
berick |
maybe this is better on the list, though.. |
| 14:04 |
berick |
websockets -- toss it on the list? |
| 14:04 |
berick |
my question is, are there any objections to moving in that direction? |
| 14:05 |
RoganH |
websockets++ |
| 14:05 |
eeevil |
I object to not moving in that direction |
| 14:05 |
berick |
:) |
| 14:05 |
berick |
i have solved the last problem, one that tsbere raised and added support for shared websocket connections across browser tabs (this morning) |
| 14:05 |
dbwells |
I object to even asking for objections |
| 14:05 |
berick |
that was my last big concern |
| 14:05 |
jeff |
berick: what is your thought/plan on server-side support for websockets? anything new from early websocket blog posts? |
| 14:06 |
bshum |
berick: I remember websocket talk from two hackaways ago, but could use a refresher too. Could you publish some more details in a dev posting for me (and others)? |
| 14:06 |
berick |
jeff: nothing has changed since my post, but i'm open to discussion. separate apache instance still seems like the best path. it will complicate the install and admin, though, which is unfortunate |
| 14:06 |
eeevil |
berick: sweet, that means 1 socket per client... that's doable (with a non-apache server for web sockets) |
| 14:06 |
berick |
eeevil: exactly (minus apache comments ;) |
| 14:07 |
jeff |
berick: slightly unfortunate, but you install far fewer times than you pass a message between client and server. ;-) |
| 14:07 |
eeevil |
or, rather, non-bloated-with-modperl-etc server |
| 14:07 |
berick |
yeah, the benefits are nice |
| 14:07 |
berick |
eeevil: right |
| 14:08 |
berick |
#action bill to open opensrf LP websocket ticket with current info |
| 14:08 |
kmlussier |
berick++ |
| 14:08 |
bshum |
berick++ |
| 14:08 |
eeevil |
berick++ |
| 14:08 |
berick |
sorry bshum, proceed :) |
| 14:08 |
jboyer-isl |
berick++ |
| 14:08 |
bshum |
berick: Heh, all good. |
| 14:09 |
bshum |
So, the OS support question I tacked on because I was just thinking about starting to look at the upcoming 14.04 Ubuntu stuff |
| 14:09 |
bshum |
The question I wanted to check is how we plan to support that? Additionally, I wanted to see if we could codify where we stood with the Debian side as well. |
| 14:10 |
gmcharlt |
for Debian, my preferred suport policy is that we support stable and oldstable |
| 14:10 |
berick |
gmcharlt: +1 |
| 14:10 |
gmcharlt |
keeping in mind that oldstable general is expected to go away a year after the release of the current stable |
| 14:10 |
jeff |
+1 stable and oldstable |
| 14:11 |
dbs |
+1 stable and oldstable |
| 14:11 |
Dyrcona |
But, I think the question at hand is how do you support new stable on day one if you haven't started working with testing? |
| 14:11 |
berick |
fwiw, i had wheezy patches on LP 6 months before it was released |
| 14:11 |
berick |
give or take, i don't remember ;) |
| 14:11 |
* csharp |
appears |
| 14:12 |
gmcharlt |
Dyrcona: fair question; but yes, supporting stable does imply that folks exercise OpenSRF and Evergreen in testing beforehand |
| 14:12 |
jeff |
it's probably time to start testing with testing/jessie. i'm happy to help. |
| 14:12 |
csharp |
I think it would be reasonable to take a similar approach to ubuntu LTS and treat the old LTS like Debian oldstable and support it for a year after a new LTS release |
| 14:12 |
gmcharlt |
jeff: just avoid running sudo apt-get install kaboom |
| 14:12 |
* Dyrcona |
always installs kaboom.... It's so much fun. :) |
| 14:13 |
jeff |
the idea being that we don't support testing until it's stable, but that devs have started incorporating support for testing into opensrf and evergreen before said debian release is released. |
| 14:13 |
jeff |
i.e., we don't recommend running your evergreen system on a not-yet-released version of debian. |
| 14:13 |
gmcharlt |
jeff: exactly |
| 14:14 |
berick |
if the trend follows, we still have well over a year before jessie is out |
| 14:14 |
dbs |
And we're not expected to shoehorn new-stable support into an old OpenSRF or Evergreen release, right? |
| 14:15 |
berick |
for debian, should we try to have installer targets, say, 6 months before the assumed release? |
| 14:15 |
csharp |
dbs: that's an even better question |
| 14:15 |
berick |
dbs: i would assume not |
| 14:15 |
csharp |
I would assume not too |
| 14:16 |
bshum |
Hmm |
| 14:16 |
gmcharlt |
I'd think it would be an option, though, but not a requirement |
| 14:16 |
|
jwoodard joined #evergreen |
| 14:16 |
gmcharlt |
particular around the time of a new stable release |
| 14:16 |
jeff |
it's likely that during the support lifetime of a given evergreen release, the two debian releases that that evergreen release supports will be shifted, and what was "oldstable" will no longer be supported by debian. I don't think we have a situation where both would shift. |
| 14:16 |
dbs |
Statement would be something like: "If you want to install on the latest Debian stable or Ubuntu LTS, please install the most recent evergreen release" |
| 14:16 |
bshum |
In that case, I think it'll be good to list out in the README of a given release which systems we support. |
| 14:16 |
dbs |
and yes, support could be optionally backported, just not mandated |
| 14:16 |
bshum |
Which was something else I was thinking to do anyways, for other reasons |
| 14:16 |
gmcharlt |
+1 to anything that encourages folks to stay up to date with EG and OpenSRF releases |
| 14:16 |
dbs |
gmcharlt++ |
| 14:17 |
jeff |
bshum: so that the "supported linux distros/versions" is codified in the branch, not just on a downloads page? is it that way now? |
| 14:17 |
gmcharlt |
and heck, I'm sure we wouldn't be the only ones to "blame" Debian for deprecating older releases ;) |
| 14:17 |
jeff |
bshum: i mean, the makefile targets are in the readme, correct? |
| 14:17 |
bshum |
jeff: Right, I think we should update all of those places. |
| 14:17 |
* dbs |
did enjoy a "upgrade OpenSRF + Evergreen + Debian inplace in one shot" upgrade once upon a time |
| 14:18 |
csharp |
yeah we did that last year with a move to Ubuntu from Debian |
| 14:18 |
bshum |
The other thing with Ubuntu is timing though. 14.04 is out a month after the intended March cycle, so if we don't support a thing till it's released, that means no official release Evergreen till the September one. |
| 14:18 |
bshum |
? |
| 14:18 |
bshum |
Unless we optionally backport |
| 14:19 |
dbs |
Right. Seems likely that that would be a chosen option |
| 14:19 |
gmcharlt |
backporting formal LTS support into 2.6.1 or 2.6.2 seems reasonable |
| 14:19 |
csharp |
+1 |
| 14:19 |
bshum |
Okay. |
| 14:19 |
Dyrcona |
When 12.04 came out, I tried to have it ready for the upcoming release in April. |
| 14:19 |
gmcharlt |
bshum: I assume Ubuntu has some mechansim for providing the equivalent of a testing socket for an upcoming LTS? |
| 14:20 |
Dyrcona |
That makes no sense. |
| 14:20 |
Dyrcona |
What I said, not what gmcharlt said. :0 |
| 14:20 |
gmcharlt |
:) |
| 14:20 |
bshum |
gmcharlt: I'm not sure, but I can try to find out. Last time I just helped Dyrcona with testing things out over time. |
| 14:21 |
csharp |
gmcharlt: yeah, you can usually be more or less stable on an LTS beta |
| 14:21 |
csharp |
similar (much shorter) testing period than Debian testing |
| 14:21 |
gmcharlt |
csharp: that sounds good enough |
| 14:21 |
Dyrcona |
I started testing Evergreen with 12.04 right after the first alpha of 12.04. |
| 14:21 |
csharp |
s/than/to/ |
| 14:22 |
Dyrcona |
I haven't started on 14.04, yet, and I agree with csharp that waiting for the beta may be reasonable. |
| 14:22 |
* Dyrcona |
checks the release schedule. |
| 14:22 |
bshum |
Ubuntu 14.04 beta1 is Feb 27th |
| 14:22 |
bshum |
(slated for) |
| 14:23 |
Dyrcona |
Right. |
| 14:23 |
bshum |
Alright, so, to summarize |
| 14:23 |
Dyrcona |
Maybe Alpha2, then. |
| 14:23 |
bshum |
OS support is generally agreed as stable and oldstable (for Debian). And current LTS and one past for Ubuntu. |
| 14:24 |
bshum |
I'll try and carve out some time to put that somewhere on the websites. |
| 14:24 |
csharp |
although interest drops out pretty fast for "one past" |
| 14:24 |
bshum |
Right |
| 14:25 |
bshum |
Okay, well, maybe we should try summarizing this into an email post to finalize and then post somewhere. |
| 14:25 |
csharp |
I mentioned above that we might consider supporting "old" LTS for a year after "new" LTS release - may have gotten lost in the Debian discussion |
| 14:25 |
csharp |
"after a year, you're on your own" |
| 14:26 |
bshum |
Good point csharp. |
| 14:26 |
bshum |
Alrighty, well, anything else to discuss today before we close this meeting? |
| 14:27 |
bshum |
Okay. |
| 14:27 |
bshum |
Thanks everyone, and enjoy the weekend. |
| 14:27 |
csharp |
bshum++ |
| 14:27 |
gmcharlt |
bshum++ |
| 14:27 |
bshum |
#endmeeting |
| 14:27 |
pinesol_green |
Meeting ended Fri Jan 10 14:27:32 2014 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 14:27 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-01-10-13.09.html |
| 14:27 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-01-10-13.09.txt |
| 14:27 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-01-10-13.09.log.html |
| 14:27 |
dbwells |
bshum++ |
| 14:27 |
ldwhalen |
bshum++ |
| 14:27 |
kmlussier |
bshum++ |
| 14:27 |
eeevil |
bshum++ |
| 14:27 |
pinesol_green |
[opensrf|Bill Erickson] recover osrf_control router start - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=b59aee4> |
| 14:28 |
kmlussier |
I just want to send along one reminder before all the devs leave. |
| 14:28 |
* bshum |
should have made his new year's wish to be more like gmcharlt and his whip of meeting timeliness. |
| 14:28 |
kmlussier |
The conference early bird registration deadline is next week. If you haven't gotten your registrations in yet, don't forget to do it by the 15th! |
| 14:28 |
kmlussier |
That is all. |
| 14:31 |
Dyrcona |
For the MARC haters: I was asked by my central site catalogers to explain MODS and its relationship to MARC21 and Evergreen. |
| 14:31 |
Dyrcona |
After the explanation, one of the catalogers asked, "So, why use MARC, then?" |
| 14:31 |
Dyrcona |
I think that made my day! |
| 14:31 |
gmcharlt |
heh |
| 14:32 |
jeff |
you must have explained it wrong. why WOULDN'T everyone want to use MARC? |
| 14:34 |
berick |
ldwhalen: one thing about the combo of TT and angular that might ease your concerns some... the prototype code is not using TT for data collections, like the TPAC. there is no mix of server-side data and client-side data. that was a concern of mine, as well |
| 14:34 |
berick |
(that also means the server-side page generation is faster) |
| 14:35 |
berick |
there is one important exception, which is that the prototype does use the locale list generated by the server, since those have to sync up a special way (and since they fetched regardless). |
| 14:35 |
berick |
all other data (models, etc.) are pure angular |
| 14:36 |
ldwhalen |
berick: I am less concerned if it is used for content modifcation like localization. None of my comments pertained to your code. I have only looked at a few files from your branch so far. |
| 14:37 |
berick |
gotcha. |
| 14:39 |
yboston |
bug 1171984 |
| 14:39 |
pinesol_green |
Launchpad bug 1171984 in Evergreen "add support in Vandelay for overlaying authorities during import using match sets" (affected: 4, heat: 18) [Wishlist,Triaged] https://launchpad.net/bugs/1171984 |
| 14:39 |
ldwhalen |
yboston: that one is on my todo. I will update launchpad |
| 14:41 |
yboston |
ldwhalen: thanks, I was just refreshing my memory on this issue. |
| 15:02 |
|
sseng_ joined #evergreen |
| 15:02 |
|
ktomita_ joined #evergreen |
| 15:02 |
|
fparks_ joined #evergreen |
| 15:05 |
|
dconnor joined #evergreen |
| 15:29 |
|
cjohnson joined #evergreen |
| 15:32 |
|
cjohnson left #evergreen |
| 15:36 |
|
cjohnson joined #evergreen |
| 15:37 |
cjohnson |
At long last I have a clue for why my Mac staff client won't save Workstation toolbars--about:config shows open-ils.menu.toolbar as blank, in Windows it is "13" |
| 15:40 |
cjohnson |
On Mac I changed the open-ils.menu.toolbar to "13" in /[user]/Library/Application Support/open_ils_staff_client/Profiles/[xyzpdq].default/prefs.js |
| 15:42 |
cjohnson |
Where is the corresponding file on Windows /Linux? Any clue why the Mac client is missing this value compared to Windows? |
| 15:43 |
ldwhalen |
cjohnson: On windows it should be in AppData/Local/OpenILS or AppData/Roaming/OpenILS |
| 15:43 |
ldwhalen |
I cannot remember which |
| 15:44 |
ldwhalen |
the smae open_ils_staff_client directory will be in one of those |
| 15:44 |
ldwhalen |
Linux it is ~/.openils/ |
| 15:47 |
cjohnson |
ldwhalen: yes you're right! Under AppData/Roaming/OpenILS! |
| 15:50 |
cjohnson |
Since we've been building clients by chopping up a working Windows client, I wonder if this explains why the value is missing from Mac clients? |
| 15:51 |
ldwhalen |
cjohnson: I was cautioned by bshum yesterday on the general list about using Windows xul builds with Mac clients, so I would say yet. |
| 15:51 |
ldwhalen |
s/yet/yes |
| 15:52 |
ldwhalen |
He mentioned that I need to use 65bit linux XUL builds with Mac clients |
| 15:52 |
ldwhalen |
64 |
| 15:52 |
cjohnson |
Does the prefs.js file get built on the first run of the client? What determines the contents? Sorry for open-ended questions- I'm a tinkerer, not programmer. |
| 15:53 |
ldwhalen |
I do not know |
| 15:54 |
cjohnson |
ldwhalen: Thanks a lot. I will try a XUL --install-app build if I can get our consortium admin to give my the tree! |
| 15:54 |
ldwhalen |
cjohnson: As well there was a recent bug with XUL and OS X Mavericks. It has been fixed, but I am not sure if the changes were added to the repo yet |
| 15:55 |
cjohnson |
my /me |
| 15:56 |
ldwhalen |
http://evergreen-ils.org/dokuwiki/doku.php?id=mozilla-devel:building_the_staff_client |
| 15:57 |
ldwhalen |
The part about info.plist needs to be correct for Maveicks. It needs he <key>CFBundleIdentifier</key> part |
| 15:57 |
ldwhalen |
Those changes will not be in the repo |
| 15:58 |
cjohnson |
For the record I've used Windows xul builds on Lion for the last year. After updating to Xul 14 it's been fast and useable. The Workstation toolbar issue is the only problem we've noticed. |
| 16:09 |
cjohnson |
ldwhalen: Thanks again--I am indeed missing the <key>CFBundleIdentifier</key> string in info.plist. Will add that and try running a fresh "install" to see if the prefs get loaded on first run |
| 16:10 |
ldwhalen |
cjohnson: the new key will not fix the prefs issue. The Staff Client will crash with out that and the corresponding <string> entry when opened in Mavericks. |
| 16:53 |
bshum |
cjohnson: So, actually, on my (Linux) workstations, that prefs.js leaves the value for open-ils.menu.toolbar left at "" |
| 16:53 |
bshum |
We make use of the library org unit setting to make ours any particular custom one per org unit. |
| 16:54 |
bshum |
13 I presume is your custom one. |
| 16:54 |
bshum |
So I think that's intended to be blank. |
| 16:56 |
|
afterl left #evergreen |
| 16:56 |
bshum |
For awhile in the old days, I think we also saw issues where some settings came across with the ID while others were basing it on the name of the workstation toolbar |
| 16:57 |
bshum |
So like "circ" or "cat" instead of "1" or "2" |
| 16:57 |
bshum |
And that mucked up saving workstation configs too |
| 16:57 |
bshum |
Not sure if that's all settled now though (it probably is) |
| 16:57 |
bshum |
I haven't used a macbook in awhile. |
| 16:59 |
bshum |
As for where prefs.js comes from, I think it is probably copied into place by the build process. |
| 17:01 |
bshum |
At the very least, I see a prefs.js in my Open-ILS/xul/staff_client/defaults/preferences/prefs.js that seems to be what we tinker with whenever we want something changed before we roll new clients. |
| 17:03 |
cjohnson |
bshum:Correct, on Windows circ is "1", cat is "2". 13 was user defined for our branch. |
| 17:06 |
bshum |
cjohnson: If everyone is going to use the same button bar at your branch, maybe it'd be better to use the library setting for "Button bar" and have that set to 13 for your library. |
| 17:09 |
cjohnson |
bshum: Sorry, clueless as to what "button bar" is :o) I am encouraged that once changing the prefs.js file or changing about:config the setting stick for the workstation |
| 17:09 |
bshum |
"Button bar" is the library setting name for the option to set a particular toolbar for the workstations of a given library. |
| 17:10 |
bshum |
Behind the scenes, I'm sure it's labeled something more closely to "toolbar" |
| 17:10 |
cjohnson |
Just trying to figure out how to install new clients that will have the toolbar setting correct as default |
| 17:11 |
|
stevenyvr2 joined #evergreen |
| 17:12 |
bshum |
Well, if that library setting was configured in your Evergreen server, then you could install any client anywhere, and by default it'd use that set toolbar if you're logging into that library. |
| 17:13 |
bshum |
Rather than worrying about building clients or fiddling with the internals. |
| 17:15 |
mmorgan |
cjohnson: We can try bshum's suggestion, I set 13 in the library setting. I have to run, but email me with how it works, I'll check my email later. |
| 17:17 |
cjohnson |
bshum: So I'm gathering you think it may be server related--or branch configuration. I had thought of this as a possibility long ago, but mystified that Linux/Windows clients worked, but not Mac |
| 17:18 |
bshum |
cjohnson: Oh I'm not excluding Mac funkiness (I'm not a fan anymore). But it seems like something that's better solved at the server level. |
| 17:18 |
cjohnson |
Aha I see mmorgan has entered--one of my admin wizards! |
| 17:18 |
bshum |
mmorgan++ |
| 17:18 |
mmorgan |
bshum++ |
| 17:18 |
mmorgan |
cjohnson++ |
| 17:19 |
cjohnson |
bhsum++ mmorgan++ |
| 17:19 |
gmcharlt |
*snort* |
| 17:19 |
gmcharlt |
an outfit called DrinkEntrepreneurs retweeted my tweet of the dev meeting minutes |
| 17:20 |
mmorgan |
Really gotta run now!! |
| 17:20 |
|
mmorgan left #evergreen |
| 17:20 |
gmcharlt |
I imagine their followers will be sorely disappointed to realize that we rarely have anything to do with http://en.wikipedia.org/wiki/Egill_Skallagr%C3%ADmsson_Brewery |
| 17:20 |
kmlussier |
gmcharlt: Ah, I was wondering if it was a result of that beer. |
| 17:21 |
bshum |
And that's why I always thought #evgils was better than #egils |
| 17:21 |
bshum |
:) |
| 17:21 |
kmlussier |
Some year, we should try to get a shipment of that beer for the #egils conference. |
| 17:21 |
bshum |
But bring on the beer! |
| 17:21 |
kmlussier |
bshum: And I noticed earlier this week that #egils was used for that egirls event again. |
| 17:22 |
gmcharlt |
kmlussier: my thoughts exactly. at the very least, the brewery should be a conference sponsor |
| 17:22 |
kmlussier |
gmcharlt: I'll send that suggestion along to afterl |
| 17:22 |
jeff |
@decide mailing or billing or physical |
| 17:22 |
pinesol_green |
jeff: http://cat.evergreen-ils.org.meowbify.com/ |
| 17:22 |
jeff |
alas. |
| 17:24 |
kmlussier |
@eightball Will I get a webteam agenda together before I have to pick up my daughter from dance class? |
| 17:24 |
pinesol_green |
kmlussier: No. |
| 17:24 |
kmlussier |
Heh, that was very clear and decisive. |
| 17:25 |
cjohnson |
OK I'm out. Wife's company is biotech and gives free beer on Fridays--I think I'll pay a visit. Thanks bshum for the help! I'll keep hammering on the Mac issue. |
| 17:25 |
* kmlussier |
's head perks up at the mention of free beer. |
| 17:27 |
cjohnson |
Apparently this is quite common in Grad School in Biotech--carries on into the startup world as well. Sanctioned drinking at work! You must find friends in Biotech! |
| 17:28 |
|
cjohnson left #evergreen |
| 17:43 |
kmlussier |
pinesol_green: Your foresight is amazing. Looks like the webteam agenda will have to wait for another day. |
| 17:43 |
pinesol_green |
kmlussier: It reads like a Nigerian 419 scam, but I think it is a sincere question sent to the wrong list. |
| 17:43 |
pinesol_green |
In #evergreen, kmlussier said: pinesol_green: Your foresight is amazing. Looks like the webteam agenda will have to wait for another day. |
| 17:44 |
kmlussier |
Yeah, yeah. G'night all! |
| 17:45 |
|
timhome_ joined #evergreen |
| 19:52 |
|
stevenyvr2 left #evergreen |
| 21:22 |
|
b_bonner_ joined #evergreen |
| 22:21 |
|
b_bonner_ joined #evergreen |
| 22:25 |
|
b_bonner joined #evergreen |
| 22:25 |
|
zerick joined #evergreen |
| 22:26 |
|
mtcarlson_away joined #evergreen |
| 22:46 |
|
stevenyvr2 joined #evergreen |
| 22:46 |
|
stevenyvr2 left #evergreen |
| 22:47 |
|
b_bonner joined #evergreen |
| 22:48 |
|
mtcarlson_away joined #evergreen |
| 22:53 |
|
linuxhiker_away joined #evergreen |
| 23:27 |
|
linuxhiker joined #evergreen |
| 23:28 |
|
b_bonner joined #evergreen |
| 23:28 |
|
mtcarlson_away joined #evergreen |
| 23:33 |
|
stevenyvr2 joined #evergreen |
| 23:34 |
|
stevenyvr2 left #evergreen |
