| Time |
Nick |
Message |
| 02:12 |
|
Rish joined #evergreen |
| 03:18 |
|
Mark__T joined #evergreen |
| 07:15 |
|
timf joined #evergreen |
| 07:40 |
|
rjackson-isl joined #evergreen |
| 07:45 |
|
jboyer-isl joined #evergreen |
| 07:56 |
|
collum joined #evergreen |
| 08:14 |
|
Dyrcona joined #evergreen |
| 08:29 |
|
akilsdonk joined #evergreen |
| 08:30 |
|
Shae joined #evergreen |
| 08:41 |
|
_bott_ joined #evergreen |
| 08:47 |
|
mmorgan joined #evergreen |
| 09:00 |
|
kbeswick joined #evergreen |
| 09:10 |
|
rfrasur joined #evergreen |
| 09:12 |
|
ericar joined #evergreen |
| 09:14 |
|
mrpeters joined #evergreen |
| 09:20 |
|
misilot joined #evergreen |
| 09:20 |
|
misilot left #evergreen |
| 09:29 |
|
RoganH joined #evergreen |
| 09:42 |
rfrasur |
bshum: do you know if someone is going to be doing a session/tutorial about acquisitions at the conference? |
| 09:44 |
bshum |
rfrasur: I don't believe anyone has stepped forward with a proposal on acq yet |
| 09:44 |
|
misilot joined #evergreen |
| 09:44 |
|
misilot left #evergreen |
| 09:44 |
rfrasur |
okay, ty |
| 09:51 |
rfrasur |
dbwells++ |
| 10:03 |
|
DPearl joined #evergreen |
| 10:19 |
|
yboston joined #evergreen |
| 11:07 |
bshum |
Today's dev meeting agenda could use more stuff, see: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2013-11-12 |
| 11:20 |
rfrasur |
jboyer-isl: Do you know offhand the patron types that have access to Overdrive? |
| 11:22 |
jboyer-isl |
I think it's Resident, PLAC, and NonResident (i.e. Fee cards, because they pay full rate). I know Reciprocals don't get it. |
| 11:23 |
rfrasur |
that's what I was thinking...trying to wrestle with the reasoning. On the surface, I get it. Underlying, I don't. |
| 11:24 |
* rfrasur |
is chafing under regulations today. |
| 11:30 |
* Dyrcona |
is choking on dry, dusty air coming from the forced air heaters in the building where he works. |
| 11:30 |
jboyer-isl |
I think it comes down to OD's restrictions. |
| 11:32 |
rfrasur |
prolly the consortial contract. I'm going to re-read it later today. So desperately annoyed with licensing...um..stuff right now. Completely undermines our ability to provide equitable, sensical service. |
| 11:32 |
* rfrasur |
shakes her fist at "the man." |
| 11:32 |
jeff |
we're simple and at the same time complex. we permit overdrive access to patrons who are in our taxing district. this is currently defined as "in one of the following zipcodes or has a specific flag (because their zipcode is an outlier), but will be transitioning over to "has a home location stat cat with one of the following values" |
| 11:32 |
csharp |
@who is the man? |
| 11:32 |
pinesol_green |
csharp: Have you tried turning it off and back on again? |
| 11:33 |
csharp |
we should really load that plugin ;-) |
| 11:33 |
Dyrcona |
@never |
| 11:33 |
pinesol_green |
Dyrcona: MARC still isn't dead yet, alas |
| 11:33 |
rfrasur |
jeff: that's what I want to forget about. I want it to be..."have a card...you're good." |
| 11:33 |
Dyrcona |
rfrasur: Good luck with that! |
| 11:34 |
* rfrasur |
knows...and hangs head in sorrow. |
| 11:34 |
jeff |
rfrasur: likely due to what was seen as "abuse" early on, publishers and therefore overdrive (and possibly without the therefore) are very touchy about non-resident access. |
| 11:34 |
Dyrcona |
Greed is not good. And anyone who thinks otherwise, totally misunderstood that movie. |
| 11:34 |
rfrasur |
heh |
| 11:34 |
csharp |
publishers-- |
| 11:35 |
Dyrcona |
Publishers are obsolete, or very soon will be. |
| 11:35 |
rfrasur |
well, I don't mind publishers other than the fact that they think we're out to get them. |
| 11:35 |
jeff |
rfrasur: if your library system is identified as one that does not have sufficient controls on which patrons can use the service, your overdrive purchasing can be restricted to a certain subset of overdrive's total catalog. |
| 11:35 |
csharp |
rfrasur: that's why they deserve the negative karma ;-) |
| 11:35 |
rfrasur |
jeff: our controls are in place. I just wish I could loosen the reins a little. |
| 11:36 |
rfrasur |
csharp: truth |
| 11:36 |
rfrasur |
and it's not so much publishers I care about. It's editors. |
| 11:37 |
rfrasur |
editors++ |
| 11:37 |
* Dyrcona |
knows a few freelance editors. |
| 11:37 |
rfrasur |
is there an editor DB? |
| 11:38 |
Dyrcona |
Some of the guilds might have one. |
| 11:38 |
rfrasur |
you don't have to answer that. it's my default question for just about everything. |
| 11:38 |
* Dyrcona |
worked in publishing for a brief period while in university. |
| 11:38 |
|
smyers_ joined #evergreen |
| 11:40 |
rfrasur |
I've wondered periodically why libraries, in general, aren't more proactive about publishing instead of just waiting around for people that hate us to offer quality stuff. |
| 11:40 |
Dyrcona |
Because historically, you do the latter, not the former. |
| 11:40 |
rfrasur |
and not just academic libraries. |
| 11:41 |
rfrasur |
um, although I like history... |
| 11:41 |
Dyrcona |
rfrasur: You should change how libraries function in the 21st century. |
| 11:41 |
Dyrcona |
jcamins: Bollocks! |
| 11:42 |
rfrasur |
Dyrcona: I shall gather minions...and do just that. |
| 11:43 |
rfrasur |
jcamins: I'm thinking about that statement. |
| 11:43 |
|
RoganH_ joined #evergreen |
| 11:44 |
jcamins |
rfrasur: unfortunately, that's what I was told in library school. |
| 11:44 |
* Dyrcona |
doesn't remember what he was told in library school. It was mostly useless anyway. |
| 11:45 |
jcamins |
Dyrcona: I hardly think that qualifies as useful information either. |
| 11:45 |
rfrasur |
jcamins: that was the jist of lib school. well, I learned SOME useful stuff, but most of it wasn't from the curriculum. |
| 11:46 |
jcamins |
Of course. |
| 11:50 |
rfrasur |
Hmm, maybe publishers SHOULD be afraid. Authors shouldn't though. |
| 11:55 |
|
smyers_ joined #evergreen |
| 11:56 |
|
ningalls joined #evergreen |
| 12:01 |
|
smyers__ joined #evergreen |
| 12:01 |
|
RoganH joined #evergreen |
| 12:29 |
|
fparks joined #evergreen |
| 12:41 |
|
smyers_ joined #evergreen |
| 12:55 |
|
stevenyvr2 joined #evergreen |
| 13:15 |
|
zerick joined #evergreen |
| 13:25 |
|
dMiller_ joined #evergreen |
| 13:34 |
|
smyers__ joined #evergreen |
| 13:35 |
|
eeevil joined #evergreen |
| 13:39 |
* paxed |
ponders |
| 13:40 |
paxed |
couple hours, and i have working code for bug 1133464 ... now to make it prettier, and configurable. |
| 13:40 |
pinesol_green |
Launchpad bug 1133464 in Evergreen "Use cover image/blurb URL from field 856" (affected: 3, heat: 14) [Wishlist,Triaged] https://launchpad.net/bugs/1133464 |
| 13:43 |
bshum |
Fancy |
| 13:43 |
paxed |
i was surprised how easy that was, actually. of course everything is currently hardcoded and whatnot, but our test server catalog looks much more colorful now... |
| 13:44 |
* rfrasur |
likes colorful things |
| 13:44 |
paxed |
hmm. now how do i query OUS in perl? |
| 13:45 |
paxed |
or perhaps this should be moved into it's own added content handler ... |
| 13:46 |
jeff |
that was the approach that i had in mind, but it should be a quick thing to do it hardcoded at the tt layer. |
| 13:47 |
paxed |
i've got it in AddedContent.pm right now |
| 13:49 |
|
mjingle joined #evergreen |
| 13:50 |
jeff |
making it its own ac handler (or teaching existing ac handlers how to look there first, or adding stacking to ac handlers in general) enables you to re-use the logic elsewhere, like in your website, etc. you get a predictable https URL that given a record id, gives you an image. |
| 13:50 |
paxed |
yup |
| 13:50 |
jeff |
sorry, i'm probably stating the obvious again. :-) |
| 13:51 |
|
artunit joined #evergreen |
| 13:52 |
paxed |
http://bilious.alt.org/~paxed/eg/images_from_856.diff the ugly first version. |
| 13:53 |
jeff |
oh. hey. s/teaching existing ac handlers how to look there first/adding it to the parent handler like paxed just did/ |
| 13:53 |
jeff |
i failed to think through that part before speaking. :-) |
| 13:54 |
|
terran joined #evergreen |
| 13:55 |
jeff |
nice. i almost think that most of the "look in these tags for these subfields with these indicators" stuff should go in opensrf.xml rather than trying to fit it in org settings. |
| 13:55 |
paxed |
yeah - i don't think there's anyway to get the perl to know which org it should look at anyway |
| 13:55 |
Dyrcona |
Can you not use MARC::Record there? |
| 13:55 |
jeff |
maybe an on/off toggle as an org setting, maybe not. all of the AC config right now is in opensrf.xml. what do you think? |
| 13:56 |
paxed |
Dyrcona: hm, i guess i could - i just didn't think of it. |
| 13:56 |
Dyrcona |
I think it would save a few lines of code. |
| 13:59 |
paxed |
9pm, i think i'll continue tomorrow. |
| 14:01 |
|
kmlussier joined #evergreen |
| 14:01 |
Dyrcona |
There is supposed to be a meeting 'bout now. |
| 14:01 |
berick |
i do believe so |
| 14:02 |
gmcharlt |
#startmeeting November 12, 2013 developer meeting |
| 14:02 |
pinesol_green |
Meeting started Tue Nov 12 14:02:01 2013 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:02 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 14:02 |
pinesol_green |
The meeting name has been set to 'november_12__2013_developer_meeting' |
| 14:02 |
gmcharlt |
#info Agenda is http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2013-11-12 |
| 14:02 |
gmcharlt |
#info gmcharlt = Galen Charlton, Equinox |
| 14:02 |
csharp |
#info csharp = Chris Sharp, GPLS |
| 14:02 |
jeffdavis |
#info jeffdavis = Jeff Davis, Sitka |
| 14:02 |
Dyrcona |
#info Dyrcona = Jason Stephenson, MVLC |
| 14:02 |
bshum |
#info bshum = Ben Shum, Bibliomation |
| 14:02 |
kmlussier |
#info kmlussier = Kathy Lussier, MassLNC (mostly lurking today) |
| 14:02 |
senator |
#info senator = Lebbeous Fogle-Weekley, Equinox |
| 14:02 |
DPearl |
#info DPearl = Dan Pearl, C/W MARS |
| 14:03 |
jeff |
#info jeff = Jeff Godin, Traverse Area District Library (TADL) |
| 14:03 |
dbwells |
#info dbwells = Dan Wells, Hekman Library (Calvin College) |
| 14:03 |
remingtron |
#info remingtron = Remington Steed, Hekman Library (Calvin College) |
| 14:03 |
phasefx2 |
#info phasefx2 = Jason Etheridge, ESI |
| 14:03 |
berick |
#info berick Bill Erickson, ESI |
| 14:04 |
ldwhalen |
#info ldwhalen = Liam Whalen, Sitka |
| 14:04 |
gmcharlt |
#topic Action items from last meeting |
| 14:05 |
gmcharlt |
looks like the bug tracking summary is to be deferred to next time |
| 14:05 |
gmcharlt |
and we have pending brain-dump doc-writing from eeevil re pgTAP and schema updates |
| 14:05 |
gmcharlt |
bshum: eeevil: anything more to say before we move on? |
| 14:06 |
bshum |
gmcharlt: Unfortunately nothing new from me. Though I'll keep trying to put into words our ever evolving methods with Launchpad |
| 14:06 |
bshum |
For the next time |
| 14:06 |
gmcharlt |
ok |
| 14:06 |
gmcharlt |
moving on |
| 14:06 |
gmcharlt |
#topics OpenSRF release |
| 14:07 |
gmcharlt |
#info OpenSRF 2.2.1 was released |
| 14:07 |
bshum |
gmcharlt++ |
| 14:07 |
gmcharlt |
#action gmcharlt needs to cut OpenSRF 2.3-beta already |
| 14:07 |
gmcharlt |
anything else re OpenSRF before we move on? |
| 14:07 |
dbwells |
gmcharlt: can you give a brief description of changes for 2.3? |
| 14:08 |
|
sidion joined #evergreen |
| 14:08 |
gmcharlt |
dbwells: briefly, a new control script and more options for using signals to control OpenSRF processes |
| 14:08 |
dbwells |
gmcharlt: thanks for the reminder |
| 14:09 |
gmcharlt |
#topic Evergreen releases |
| 14:09 |
gmcharlt |
#info Evergreen 2.5.0 is out! |
| 14:09 |
jeff |
dbwells++ # 2.5 release :-) |
| 14:09 |
gmcharlt |
dbwells++ |
| 14:09 |
csharp |
dbwells++ |
| 14:09 |
berick |
dbwells++ |
| 14:09 |
phasefx_ |
dbwells++ |
| 14:09 |
berick |
yay |
| 14:09 |
bshum |
dbwells++ indeed! |
| 14:10 |
dbwells |
yay indeed! |
| 14:10 |
berick |
2.3.next will be cut at the usual monthly time |
| 14:10 |
kmlussier |
dbwells++ |
| 14:10 |
DPearl |
dbwells++ |
| 14:11 |
bshum |
berick: Related, there's just a few hanging 2.3 backports to go. If we put those in, maybe this is the last 2.3? |
| 14:11 |
bshum |
(unless there's more security fixing) |
| 14:12 |
berick |
oh, right, we're almost EOL for 2.3 |
| 14:12 |
dbwells |
berick: I did mention 2.3 being phased out in the 2.5 email, but tried to leave the door open for whatever you want to do with that timing-wise |
| 14:13 |
berick |
i'll review the pending backports and see what's what |
| 14:13 |
dbwells |
berick: I also left it as "Stable" on the downloads page, so that will need to be changed at some point as well. |
| 14:15 |
gmcharlt |
anything more to say about 2.3 or 2.4? |
| 14:15 |
berick |
dbwells: *nod* and thanks |
| 14:16 |
gmcharlt |
ok, moving on |
| 14:16 |
gmcharlt |
#topic Releae manager for 2.6 |
| 14:16 |
|
smyers_ joined #evergreen |
| 14:17 |
Dyrcona |
I put the new business items on the agenda, because I know that two of them are things we need to talk about/vote on. |
| 14:18 |
Dyrcona |
dbwells sent an email to the dev list this morning where he basically volunteered to be RM for 2.6. |
| 14:18 |
|
tsbere joined #evergreen |
| 14:19 |
remingtron |
jos |
| 14:19 |
* berick |
wonders why he's not seeing this email |
| 14:19 |
berick |
to the archives |
| 14:19 |
remingtron |
sorry, wrong window |
| 14:20 |
gmcharlt |
#link http://libmail.georgialibraries.org/pipermail/open-ils-dev/2013-November/009149.html |
| 14:20 |
dbwells |
I hope people got a chance to read it, but what Dyrcona said is a reasonable 20 word or less summary of my ~300 words :) |
| 14:21 |
bshum |
Slightly better formatting: http://markmail.org/message/54ffdrtc2ofc6qjo |
| 14:23 |
berick |
while we're all here, does anyone else plan to throw a hat in the ring? |
| 14:23 |
gmcharlt |
from my POV, while I support dbwells as RM for 2.6, voting the same day as the proposal seems rushed -- I propose that we give a week, then assent via email if no other proposal is made |
| 14:23 |
berick |
+1 |
| 14:23 |
phasefx2 |
+1 |
| 14:23 |
jeff |
+1 |
| 14:23 |
Dyrcona |
+1 |
| 14:24 |
csharp |
I think I made the point at the Hackaway that we are pretty much at the point where we have exhausted the pool of available/qualified/willing candidates ;) |
| 14:24 |
csharp |
+1 |
| 14:24 |
kmlussier |
+1 |
| 14:24 |
DPearl |
+1 |
| 14:24 |
dbwells |
I can also flesh out a proposal if people really want it, but my cliff notes version would be, "More of the same, but faster!" |
| 14:25 |
csharp |
dbwells++ |
| 14:25 |
jeff |
dbwells++ |
| 14:25 |
Dyrcona |
dbwells++ |
| 14:25 |
phasefx2 |
"We have the technology" |
| 14:25 |
gmcharlt |
indeed we do |
| 14:25 |
gmcharlt |
OK, so moving on |
| 14:26 |
gmcharlt |
#topic Proposal: make 2.6 a stability release and putting new development into 3.0 |
| 14:26 |
gmcharlt |
Dyrcona: the floor is yours |
| 14:26 |
Dyrcona |
This comes out of something dbwells mentioned in his email, about the next release being compressed into 4 months. |
| 14:27 |
Dyrcona |
When I thought about it, that doesn't seem like a lot of time. |
| 14:27 |
Dyrcona |
It seems to me, too, that we do have some trouble hitting our feature release very 6 months deadlines. |
| 14:28 |
Dyrcona |
I don't think that is the fault of the release manager. I think our resource pool is just too small and most have other responsibilities. |
| 14:28 |
Dyrcona |
What I am proposing is that whatever new features are ready by the deadline, go into 2.6. |
| 14:28 |
kmlussier |
Dyrcona: With this proposal, are you saying any new development done over the next two or three months would need to wait until a Fall 2014 release? |
| 14:29 |
Dyrcona |
Um, no, but our messages crossed. :) |
| 14:29 |
kmlussier |
Dyrcona: Sorry. I spoke too quickly. Continue. :) |
| 14:29 |
berick |
oohhh |
| 14:29 |
berick |
i had the same confusion |
| 14:29 |
Dyrcona |
After that, I think 2.6 should be frozen and maintained for bug fixes for some unknown amount of time. |
| 14:30 |
Dyrcona |
I think a 3.0 branch could be cut or master used for new feature development. |
| 14:30 |
Dyrcona |
And here, I'm talking big things, like the web-only staff client, etc. |
| 14:30 |
bshum |
New like web-base... yeah |
| 14:30 |
Dyrcona |
That would be released when the list of features are ready. |
| 14:30 |
eeevil |
Dyrcona: and would 3.0 be delayed for some currently-unspecified amount of time? |
| 14:30 |
berick |
Dyrcona: you're kind of describing the way I thought things already worked (in theory). |
| 14:31 |
dbwells |
So the big change is that 3.0 becomes unscheduled? |
| 14:31 |
Dyrcona |
eeevil: yes. For these two releases, we'd be abandoning the "current" release schedule, that I don't think is working, but I could be wrong. |
| 14:31 |
eeevil |
ok, so, make 2.6 the last timed release until 3.0, which might be 12, 18 or 24 months out |
| 14:31 |
Dyrcona |
Basically, yes. |
| 14:32 |
eeevil |
the problem with that, that time releases are supposed to address, is that new features will take forever to appear |
| 14:32 |
csharp |
I think we're more like Fedora, where we're scheduling every six months but accept delays |
| 14:32 |
eeevil |
instead of only being delayed by one cycle at most |
| 14:32 |
csharp |
rather than Ubuntu's clockwork thing ;-) |
| 14:32 |
jeff |
Dyrcona: you mentioned Linux 2.6 vs 3.0. was that just that the numbering happened to coincide, or is there a practice you're thinking of patterning this after? |
| 14:33 |
eeevil |
or, that's my understanding of (one of the) motivations of timed releases |
| 14:33 |
Dyrcona |
jeff: Just because the numbering happened to coincide. The linux 2.6/3.0 is a bit different. |
| 14:34 |
jeff |
Dyrcona: got it. thanks for clearing up my misunderstanding. :-) |
| 14:34 |
Dyrcona |
Also, when I said "stable" I mean a stable feature set. Not what most people think of when they say "stable." |
| 14:35 |
csharp |
if 2.6 remains a stable code base, back porting new features should be doable, right? |
| 14:35 |
eeevil |
isn't that the case now? 2.5 won't get any new features, but will get bug fixes for 15 months... |
| 14:35 |
dbs |
#info dbs = Dan Scott, Laurentian University (LATE) |
| 14:35 |
jeff |
The big downside that I see is new features stop for an unknown amount of time unless you're running pre-release in production. What do you see as the advantages? |
| 14:35 |
csharp |
or is that the point - 2.6 stays "new-feature-free"? |
| 14:35 |
eeevil |
#info eeevil = Mike Rylander, ESI (also late) |
| 14:36 |
jeff |
csharp: depends on if the backported bits rely on larger underlying changes. |
| 14:36 |
Dyrcona |
eeevil: To be frank, I'm not sure we have the community to support new features every 6 months. |
| 14:36 |
|
mllewellyn joined #evergreen |
| 14:37 |
eeevil |
Dyrcona: now /that/ I agree with. I think a 12mo cycle is more our speed if we stay timed. but that still keeps new features out of folks hands for a long time |
| 14:37 |
eeevil |
the other end of the spectrum is constant release, with some marked with a version number and tar'd up for download |
| 14:38 |
Dyrcona |
eeevil: At the risk of burning a lot of karma, I think "the folks" are a part of the problem. |
| 14:38 |
eeevil |
Dyrcona: "the folks" are the libraries using evergreen... so... |
| 14:38 |
Dyrcona |
What I hear from the "community" is that they want the features, like yesterday, but they don't want bugs, and then they systematically stay 2 releases behind. |
| 14:39 |
* berick |
wonders what features are taking 8 months to develop |
| 14:39 |
Dyrcona |
Everything that went into 2.5. |
| 14:39 |
eeevil |
berick: full authority browse was one (though not 8mo of constant typing) |
| 14:40 |
dbs |
Well, not every place is 2 releases behind, and not every feature takes longer than 6 months |
| 14:40 |
RoganH |
#info RoganH = Rogan Hamby, SCLENDS |
| 14:40 |
Dyrcona |
Of course I'm generalizing. Who has time for specifics in IRC? |
| 14:40 |
berick |
so the problem is that releases go into master before they are release ready? |
| 14:40 |
RoganH |
Not everyone is 2 behind but for example in SCLENDS my directors have demanded to be one release behind to avoid bugs. |
| 14:40 |
Dyrcona |
No. |
| 14:40 |
berick |
and thus delay the release? |
| 14:41 |
bshum |
So specific.... and stop me if I'm asking a stupid question. |
| 14:41 |
eeevil |
dbs: absolutely. I'm still enamored of "stamp arbitrary way-points as releases" |
| 14:41 |
jeff |
Dyrcona: I'm not sure I understand the advantage to what you're proposing. Is the idea to give a supported release to those libraries that currently are upgrade-averse, so that they're not running "unsupported"? |
| 14:41 |
bshum |
Of particular concern to me is our transition to using web based clients, as we've discussed, and have prototypes underway and such. |
| 14:41 |
dbwells |
2.4 was released on May 3, and 2.5 on Nov. 8, so that's 6 months and 5 days for 2.5. (but who's counting? :P) |
| 14:41 |
dbs |
TPAC evolved over a number of releases to eventually replace JSPAC, I think that's a good example of something that took > 6 months to develop, and did so iteratively |
| 14:41 |
* gmcharlt |
observes that the web-based client is *not* an all-or-nothing thing |
| 14:41 |
bshum |
Do we expect there to be new features built on top of our existing xul/dojo infrasture that also need to be ported into the web client? |
| 14:42 |
berick |
dbs++ |
| 14:42 |
jeff |
Dyrcona: apologies, because I've so far misunderstood a few aspects of the propsal, but how would the proposed 3.0 differ from master today? |
| 14:42 |
Dyrcona |
jeff: I haven't worked out all of the details. I wanted to throw this out there as something to discuss. |
| 14:42 |
eeevil |
and to be fair, the same happened with bib browse. the bib part came first, and the authority part later ... they just happened to drop in the same release |
| 14:43 |
rfrasur |
#info rfrasur = Ruth Frasur, Evergreen Indiana |
| 14:43 |
bshum |
gmcharlt: Fair enough. |
| 14:43 |
eeevil |
bshum: that will, with out a doubt, have to happen to some degree, IMO |
| 14:44 |
eeevil |
bshum: until there is actual momentum on web-based, AND coverage of the more complicated staff UIs |
| 14:44 |
bshum |
To me, that's something that could happen with a freeze at 2.6 ending xul/dojo work and letting us focus on a transition to other things in 3.0 without having to split all of our focuses. But maybe I'm not thinking big enough. |
| 14:45 |
eeevil |
we all agree that pretty much everything can be developed itteratively |
| 14:45 |
jeff |
Another approach would be to freeze some staff interfaces as web interfaces mature, and not tie it to an entirely feature-frozen release. |
| 14:46 |
eeevil |
and some plurality of us content that 6mo is short for our dev resources |
| 14:47 |
gmcharlt |
and a plurality (?) not particularly desirous of an indefinite schedule |
| 14:47 |
* berick |
still does not understand how 6mo is short |
| 14:47 |
eeevil |
(s/content/conted/) and some other, partially overlapping pluratily contends that longer than 6mo is painful to wait for some new features, due to scheduling |
| 14:47 |
rfrasur |
I'd just like to throw in there as one of "the folks" - one reason that it takes so long to move to the new release is that after the features are available, we have to go through a lot of procedural stuff to make sure it works for all our members and basically factor in the human element. Personally, I'd love to move to 2.5 yesterday, but it's just not feasible when you're dealing with 102/3 libraries with people workin |
| 14:47 |
rfrasur |
at them. |
| 14:48 |
bshum |
eeevil: I agree that we can develop iteratively, but people have gotten burned by using those features iteratively by following the latest releases. I think of all our fun with acq since 2.0 in that sense. |
| 14:48 |
Dyrcona |
rfrasur: I'm aware of that, believe me, I'm aware of that. |
| 14:48 |
* eeevil |
type good... |
| 14:48 |
senator |
this is definitely more complex than an up/down vote on dyrcona's initial suggestion |
| 14:48 |
rfrasur |
;), just so you know that it's not that we're breathing down the developer's neck only to walk away and ignore whatever work's been done. |
| 14:48 |
senator |
i think we ought to hash this out on the list |
| 14:48 |
Dyrcona |
Well, may I suggest that we table this or even throw it out the window? |
| 14:49 |
Dyrcona |
senator++ |
| 14:49 |
eeevil |
bshum: I can't argue with the counter-example of acq, except to say that that's about as complicated as you can get ... I can't think of another similar example |
| 14:49 |
csharp |
senator: +1 |
| 14:49 |
gmcharlt |
#info Discussion of the proposal to be moved to open-ils-dev |
| 14:49 |
gmcharlt |
#topic Requiring automated tests for new code/database modifications. |
| 14:49 |
eeevil |
anyway, my point was, am I alone in seeing the "arbitrary waypoints as versioned releases" as a way around much of this? |
| 14:50 |
eeevil |
and with that, I'll hush |
| 14:50 |
gmcharlt |
eeevil: no, you're not, but that implies some things that we don't have yet but hopefully will accumulate over time |
| 14:50 |
gmcharlt |
that actually was an excellent seque into the current topic :) |
| 14:51 |
jeff |
heh. |
| 14:51 |
jeff |
gmcharlt++ |
| 14:51 |
Dyrcona |
I put this on the agenda, too. |
| 14:51 |
* Dyrcona |
ducks. |
| 14:52 |
Dyrcona |
I think dbs email was a call for this to be more formal and eeevil and others have made strides in that direction. |
| 14:52 |
Dyrcona |
This, I hope, we could actually "vote" on. |
| 14:53 |
dbs |
I think we could make pgTAP tests for database changes a matter of policy. Not sure if we're ready for requiring tests for general code modifications though |
| 14:54 |
jeff |
I think that all-or-nothing "no commits without matching unit tests" is impractical given our current testing infrastructure. Starting with database changes where we have pgTAP seems like a good beginning. |
| 14:54 |
jeff |
"Encouraged" elsewhere, and we can transition to "required" as our testing methodologies mature. |
| 14:54 |
dbs |
FWIW, I thought August's dev meeting had already voted on the pgTAP test requirement? |
| 14:54 |
dbs |
jeff++ |
| 14:55 |
Dyrcona |
Was that a vote on a requirement? |
| 14:55 |
* phasefx2 |
thought that was an "ease into it" |
| 14:56 |
dbs |
phasefx2 is right |
| 14:56 |
dbs |
http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-08-27-14.04.log.html |
| 14:56 |
RoganH |
As someone who handles contracts for development rather than development myself I wish it was a requirement. When I get competing bids and vendor X says we can cut costs for you by not doing tests that seems attractive to some of my members - the same ones who complain about unexpected behavior of course but still. |
| 14:57 |
Dyrcona |
As a developer, I'd have to learn to do the tests... |
| 14:57 |
Dyrcona |
I think the rumblings are that devs in general would like to see these be required. |
| 14:58 |
jeff |
browsing "git log -- Open-ILS/src/sql/Pg/upgrade", i don't know if i can say without a doubt that every recent change immediately lends itself to having a unit test. |
| 14:58 |
gmcharlt |
#startvote Shall pgTAP test cases (where applicable) be required for new commits starting with 2.6? Yes, No, Postpone |
| 14:58 |
pinesol_green |
Begin voting on: Shall pgTAP test cases (where applicable) be required for new commits starting with 2.6? Valid vote options are Yes, No, Postpone. |
| 14:58 |
pinesol_green |
Vote using '#vote OPTION'. Only your last vote counts. |
| 14:59 |
phasefx2 |
#vote Yes |
| 14:59 |
berick |
gmcharlt: to clarify, 2.6 means staring now w/ all new features? |
| 14:59 |
jeff |
Is this meaningless if we don't have a good idea of what "where applicable" means? |
| 14:59 |
eeevil |
jeff: not all do. I'm fine with being called out when I don't add one that could |
| 14:59 |
bshum |
"where applicable" is vague enough that given my general infamiliarity with pgTAP use, I'm not sure I'm ready to commit to that. |
| 14:59 |
phasefx2 |
you can make an assertion about any upgrade script; at the very least, it might help someone check that they actually ran a required upgrade script |
| 14:59 |
RoganH |
#vote Yes |
| 14:59 |
phasefx2 |
but coming up with mock environments to test behavior for stored procedures.. that might be a bit much for some folks |
| 15:00 |
bshum |
But I'm among the "have to learn to do the tests..." folks |
| 15:00 |
gmcharlt |
berick: yes -- though the RM may have the option to exercise discretion |
| 15:00 |
berick |
thanks |
| 15:00 |
berick |
#vote YES |
| 15:00 |
phasefx2 |
if doing an independent unit test as oppossed to relying on concerto test data |
| 15:00 |
eeevil |
gmcharlt: s/may/should/ IMO |
| 15:00 |
berick |
tis inevitable |
| 15:00 |
gmcharlt |
bshum: in my view, a requirement will encourage folks to learn the framework |
| 15:01 |
gmcharlt |
eeevil: agreed |
| 15:01 |
gmcharlt |
#vote Yes |
| 15:01 |
dbwells |
#vote Yes |
| 15:01 |
eeevil |
#vote yes |
| 15:02 |
dbwells |
I am anxious to see how this will play out in practice, but it certainly can't hurt to try. |
| 15:02 |
jeffdavis |
gmcharlt: or conversely, folks who might otherwise contribute a patch might decide it's too difficult |
| 15:02 |
jeffdavis |
(not that I'm opposed to unit tests) |
| 15:02 |
gmcharlt |
jeffdavis: the requirement applies to the commit, not the person, IMO |
| 15:02 |
eeevil |
dbwells: in practice, you'll get to threaten revert unless a test shows up :) |
| 15:03 |
gmcharlt |
IOW, a more experienced dev helping write unit tests for a patch originated by somebody else would be a Good Thing |
| 15:03 |
csharp |
can buildbot run the tests? |
| 15:03 |
berick |
dbwells: you are this -><- close to be elected benevolent overlord |
| 15:03 |
csharp |
(thinking of pgTAP) |
| 15:03 |
csharp |
berick++ |
| 15:03 |
phasefx2 |
csharp: ultimately yes |
| 15:04 |
jeff |
If I'm crafting a database upgrade script and base-schema changes to add a new org unit setting type, 1) is that "where applicable" and requires a pgTAP test? and 2) What is tested -- test for successful insertion / existence in config.org_unit_setting_type? |
| 15:04 |
jeffdavis |
which could mean experienced devs spend more time on others' patches, or that those patches languish |
| 15:04 |
jeffdavis |
again, I'm not opposed, but I do worry a bit about the downsides |
| 15:04 |
eeevil |
jeff: that's a case where it seems useless. we have config.upgrade_log for that |
| 15:04 |
bshum |
Not all committers are made equal. I say this as the timid one of the group here. |
| 15:05 |
dbs |
#vote yes |
| 15:05 |
bshum |
In principle, I agree; I just won't say when I'm ready till I know more. |
| 15:05 |
bshum |
#vote yes |
| 15:05 |
jeff |
jeffdavis: I think that "patches languishing" can be evaluated at a time afterward. If there's an issue, the decision can be re-evaluated or additional steps can be taken to make things easier to test, etc. |
| 15:05 |
berick |
jeff: good question. imo, seed data that's not used by the DB (only the app) is not really worth the effort of testing in pgtap; app-level tests, sure. |
| 15:05 |
dbs |
code reviewers will certainly help where needed methinks |
| 15:06 |
eeevil |
also, my as yet unsent plan for non-changing base schema would reduce the overhead of this... |
| 15:06 |
gmcharlt |
and requiring unit tests can help promote more code review |
| 15:06 |
* eeevil |
-- |
| 15:06 |
phasefx2 |
jeff: there's also automated test creation for simple things like that, that we may want to think about |
| 15:06 |
gmcharlt |
(and I've seen evidence of that in Koha-land) |
| 15:06 |
dbs |
(For 2.6 I'd kind of like to make good on the threat others have for pulling the fake org_unit stuff out of seed data and into concerto & friends) |
| 15:07 |
jeff |
Okay. Further questions about "where applicable" and such to be sought on open-ils-dev, where you can either find help in conceptualizing / creating a test, or concensus on "not applicable"? |
| 15:07 |
dbs |
(But that's a different subject :) ) |
| 15:07 |
Dyrcona |
#vote postpone # cause there's no "abstain" option other than not voting. |
| 15:07 |
pinesol_green |
Dyrcona: postpone # cause there's no "abstain" option other than not voting. is not a valid option. Valid options are Yes, No, Postpone. |
| 15:07 |
bshum |
dbs: +1 |
| 15:07 |
Dyrcona |
#vote postpone |
| 15:07 |
gmcharlt |
Dyrcona: because it's your own proposal, or because the parameters I set for the vote don't match what you have in mind? |
| 15:07 |
csharp |
dbs: +1 |
| 15:08 |
Dyrcona |
gmcharlt: Because I'm actually ambivalent about the topic. |
| 15:08 |
Dyrcona |
I brought it up because I think we need some official clarity on the matter. |
| 15:09 |
Dyrcona |
Well, what passes for official around here, anyway. :) |
| 15:10 |
jeff |
#vote Yes |
| 15:10 |
senator |
#vote Yes |
| 15:10 |
dbs |
Dyrcona++ |
| 15:10 |
gmcharlt |
Dyrcona: you didn't seen the Officail Badge dbwells has been wearing for the past few months? |
| 15:10 |
gmcharlt |
anyway |
| 15:10 |
gmcharlt |
#endvote |
| 15:10 |
pinesol_green |
Voted on "Shall pgTAP test cases (where applicable) be required for new commits starting with 2.6?" Results are |
| 15:10 |
pinesol_green |
Yes (10): jeff, berick, RoganH, dbwells, gmcharlt, bshum, senator, dbs, phasefx2, eeevil |
| 15:10 |
pinesol_green |
Postpone (1): Dyrcona |
| 15:11 |
gmcharlt |
#agreed pgTAP test cases (where applicable) are required for new commits start with 2.6 |
| 15:11 |
phasefx2 |
yay |
| 15:11 |
gmcharlt |
any other last minute insertions before we end the meeting? |
| 15:12 |
gmcharlt |
... |
| 15:12 |
gmcharlt |
#endmeeting |
| 15:12 |
pinesol_green |
Meeting ended Tue Nov 12 15:12:34 2013 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:12 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-11-12-14.02.html |
| 15:12 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-11-12-14.02.txt |
| 15:12 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-11-12-14.02.log.html |
| 15:12 |
phasefx2 |
gmcharlt++ |
| 15:12 |
csharp |
gmcharlt++ |
| 15:13 |
dbwells |
gmcharlt++ |
| 15:13 |
csharp |
like a baus |
| 15:13 |
remingtron |
gmcharlt++ |
| 15:13 |
jeff |
gmcharlt++ # meeting wrangling |
| 15:13 |
* phasefx2 |
thinks gmcharlt should get an official badge too |
| 15:14 |
dbwells |
phasefx2: but it's... my precious! |
| 15:14 |
Dyrcona |
:) |
| 15:14 |
rfrasur |
dbwells++ |
| 15:55 |
jeff |
oh weird. |
| 15:57 |
jeff |
pg_dump / pg_restore changed part of a view definition from "'2008-09-28 00:00:00-04'::timestamp with time zone" to "'2008-09-28 04:00:00+00'::timestamp with time zone" |
| 16:00 |
jeff |
same version of pg_dump / pg_restore, but the original dumping host and the restoring host differ in their default timezone. |
| 16:00 |
jeff |
timezones-- dst-- |
| 16:01 |
rfrasur |
+1 for so many reasons |
| 16:02 |
|
smyers__ joined #evergreen |
| 16:04 |
eeevil |
jeff: hey, that's the same time. whatchawant? |
| 16:04 |
jeff |
a clean diff. :-) |
| 16:04 |
eeevil |
fair |
| 16:08 |
BigRig |
phasefx2: I need to get this cough looked at. I scheduled a dr apt for 12:00 pm on Wednesday so I may be a bit long on my lunch hour. How do you want me to record that info? |
| 16:09 |
phasefx_ |
don't spread it here :) |
| 16:09 |
bradl |
hah |
| 16:09 |
jeff |
eeevil: could be worse. pg_dump used to use timezone abbreviations, which are not unique, so depending on if you had COMPILED with "australian rules" enabled, your dump of EST on one system would restore as something quite different on another. |
| 16:10 |
eeevil |
:) |
| 16:11 |
gmcharlt |
so, has anybody updated their servers to use the proposed two-timezone split of North American? |
| 16:11 |
* gmcharlt |
ducks |
| 16:12 |
jeff |
and let's just say i'm glad we don't have circ transactions with Manila timezones in the mid-1800s |
| 16:13 |
jeff |
"why can't I pg_restore my data?" "because the Olson database generally uses local mean solar time for the named city as the reference point in years before that locality adopted any official standard time reference." |
| 16:16 |
gmcharlt |
jeff: and how does one calculate the overdue fine for a book checked out from British Library, due on 8 September 1752? |
| 16:17 |
berick |
@dunno add have you tried local mean solar time for the named city as the reference point? |
| 16:17 |
pinesol_green |
berick: 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). |
| 16:17 |
jeff |
gmcharlt: with a press release forgiving the ambassador retroactively for his very overdue book, using a made up figure and a modifier such as "over" or "in excess of" |
| 16:18 |
gmcharlt |
jeff: which in turn would be followed by a press release saying, in essence: "8 September 1752? Nobody knows of such a date here" |
| 16:18 |
* rfrasur |
sends reply to maintenance person that simply says "rock on" and then wonders at the professionalism of such a reply. |
| 16:20 |
berick |
hmm, let's see if that did it |
| 16:21 |
berick |
@dunno add have you tried local mean solar time for the named city as the reference point? |
| 16:21 |
pinesol_green |
berick: The operation succeeded. Dunno #23 added. |
| 16:23 |
Dyrcona |
professionalism? |
| 16:23 |
rfrasur |
something I aspire to....but never quite attain. |
| 16:26 |
RoganH |
Remember that professionalism is relative to the profession. A circus juggler who swallows live mice has a different standard than a library director. |
| 16:26 |
RoganH |
[ note that I don't say it's higher or lower ... ] |
| 16:27 |
rfrasur |
Hmm....good point, RoganH. I'll have to think about librarianship as a profession. Maybe I aspire to what I think it SHOULD be? |
| 16:33 |
rfrasur |
Our lib was only 130ish places out of LJ rankings :D (and I think it's going to drop next year) |
| 16:48 |
|
smyers_ joined #evergreen |
| 17:20 |
|
mmorgan left #evergreen |
| 17:25 |
|
kbeswick joined #evergreen |
| 18:20 |
|
stevenyvr2 left #evergreen |
| 18:28 |
|
dMiller_ joined #evergreen |
| 19:43 |
|
linuxpoet joined #evergreen |
| 19:43 |
linuxpoet |
What is the recommended Perl version for Evergreen |
| 19:52 |
|
kbeswick joined #evergreen |
| 20:17 |
|
kbeswick joined #evergreen |
| 20:50 |
|
linuxpoet joined #evergreen |
| 20:56 |
|
dbs_mob joined #evergreen |
| 20:57 |
dbs_mob |
linuxpoet: generally whatever Debian or Ubuntu LTS have |
| 20:57 |
dbs_mob |
there is a known problem with recent versions of Encode.pm |
| 20:58 |
dbs_mob |
(I ran into that on Fedora and put a branch together that seems to fix the problem, with significant help from dbwells, but it had not yet been merged) |
| 21:01 |
linuxpoet |
dbs_mob: is the problem with Encode documented? (We ran into it too) |
| 21:16 |
eeevil |
@later tell linuxpoet yes, well documented by dbs and dbwells: https://bugs.launchpad.net/evergreen/+bug/1242999 |
| 21:16 |
pinesol_green |
eeevil: The operation succeeded. |
| 21: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] |
| 21:53 |
|
linuxpoet joined #evergreen |
| 22:02 |
|
mrpeters joined #evergreen |
| 22:11 |
|
linuxpoet joined #evergreen |
| 22:15 |
|
linuxpoet joined #evergreen |
