| Time |
Nick |
Message |
| 01:11 |
|
dcook__ joined #evergreen |
| 02:49 |
|
akilsdonk joined #evergreen |
| 06:15 |
|
mtate joined #evergreen |
| 06:15 |
|
eeevil joined #evergreen |
| 06:16 |
|
phasefx joined #evergreen |
| 06:16 |
|
maryj joined #evergreen |
| 06:16 |
|
TaraC joined #evergreen |
| 06:16 |
|
BigRig joined #evergreen |
| 06:16 |
|
Callender joined #evergreen |
| 06:17 |
|
graced joined #evergreen |
| 07:18 |
|
jboyer-isl joined #evergreen |
| 07:57 |
|
akilsdonk joined #evergreen |
| 08:01 |
|
collum joined #evergreen |
| 08:10 |
|
ericar joined #evergreen |
| 08:11 |
|
julialima_ joined #evergreen |
| 08:35 |
* csharp |
idly wonders how hard it would be to add regex capabilities to the reporter |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:39 |
|
mrpeters joined #evergreen |
| 08:42 |
|
Dyrcona joined #evergreen |
| 08:51 |
|
Shae joined #evergreen |
| 08:51 |
|
Stompro joined #evergreen |
| 08:54 |
|
jwoodard joined #evergreen |
| 08:57 |
|
Dyrcona joined #evergreen |
| 09:18 |
|
rjackson-isl joined #evergreen |
| 09:21 |
jeff |
csharp: always helps to have an example or use case... |
| 09:27 |
Dyrcona |
Debian package maintainers strike again! |
| 09:28 |
Dyrcona |
Pakaging erlang with the distributed features turned off. |
| 09:29 |
Dyrcona |
Thereby defeating the whole point of erlang. |
| 09:29 |
tsbere |
Supposedly fixed, but not on any version we are running on our end. <_< |
| 09:29 |
tsbere |
(which broke me testing stuff with it this weekend) |
| 09:30 |
jeff |
"Oh honey, he's teasing you. Nobody has TWO computers." |
| 09:36 |
kmlussier |
berick: We're due for another Bug Squashing Day in February. But I don't want it to interfere with 2.8 release activities. Do you have any thoughts on what timing would work best? |
| 09:36 |
kmlussier |
Maybe we should put it off until March. |
| 09:38 |
kmlussier |
Looking at our August calendar, it looks like our first Bug Squashing Day was held 2-3 weeks after the beta release. |
| 09:39 |
bshum |
Bug squashing day was nice for the release imo. Just in that it got more review of things into the release. More bug fixes = good. |
| 09:40 |
kmlussier |
bshum: Sure, but I think it's good to do it after the beta release since the weeks leading up to beta are so focused on new features. |
| 09:40 |
bshum |
Post beta, it's all about stabilization anyways. Since new features are cut off. |
| 09:40 |
bshum |
Precisely |
| 09:41 |
kmlussier |
I'm thinking the first 2 weeks of March are good candidates. |
| 09:42 |
kmlussier |
Or maybe between beta and RC1? |
| 09:44 |
bshum |
Before RC sounds best to me. |
| 09:45 |
bshum |
A release candidate is supposed to be as ready to ship as possible. Or so I was told anyways during 2.7. |
| 09:56 |
|
RoganH joined #evergreen |
| 10:01 |
csharp |
jeff: oh, just wanted to identify bib records for DVDs that were coded to be "laserdisc" which was throwing off our format icons in 2.7 |
| 10:02 |
bshum |
Laserdiscs strike again! :) |
| 10:02 |
csharp |
specifically, I wanted to be able to have an expression like "^v. .g" be available via the reports interface so our cataloging staff could be more self-sufficient ;-) |
| 10:03 |
csharp |
I think I only saw one or two laserdiscs in my life |
| 10:03 |
csharp |
had a cousin with a player and maybe two movies for it back in the early 80s |
| 10:10 |
RoganH |
I had the original Star Wars trilogy on laser disc, still have the discs but the player died years ago. |
| 10:10 |
berick |
kmlussier: bshum: as soon after the beta cut as possible seems ideal to me (consistent w/ what you all are saying) |
| 10:11 |
kmlussier |
berick: OK, thanks. I'll put a Doodle poll out shortly. |
| 10:24 |
jboyer-isl |
csharp, It may not be ideal, but can't a report be written now that uses the Fixed Field Entries link from Bib Record to find those? (I'll admit I'm not 100% certain how you differentiate DVD and LD right now.) |
| 10:24 |
jboyer-isl |
And now to a meeting... |
| 10:29 |
csharp |
jboyer-isl: thanks for the suggestion! I'll take a look |
| 10:32 |
Dyrcona |
csharp: We had hundreds (maybe thousands) of DVDs cataloged as laser discs. |
| 10:33 |
Dyrcona |
As for seeing actual laser discs, I've seen hundreds, but I have a friend who is an A/V geek/independent film maker, and collects all kinds of that stuff. |
| 10:34 |
csharp |
we have ~7500 records |
| 10:34 |
Dyrcona |
csharp: sounds about right, and guess what my next line is going to be. |
| 10:35 |
* csharp |
guesses "marc--" |
| 10:38 |
Dyrcona |
Nope, "I have a script." |
| 10:38 |
csharp |
Dyrcona: oh? is it in your git repo? |
| 10:38 |
csharp |
oh and |
| 10:38 |
csharp |
marc-- |
| 10:38 |
Dyrcona |
This one isn't. I thought it was too specific. |
| 10:38 |
csharp |
makes sense |
| 10:40 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "laserdisc_fix.pl" (207 lines) at http://paste.evergreen-ils.org/25 |
| 10:41 |
csharp |
Dyrcona++ # thanks! |
| 10:41 |
Dyrcona |
That was worked out with our central site catalogers. Things it doesn't fix go in a bucket. |
| 10:41 |
csharp |
oh - excellent |
| 10:41 |
Dyrcona |
It doesn't try to fix records with multiple 007s, for instance, but that was only a handful of our records, IIRC. |
| 10:56 |
jeff |
i own a few dozen laserdiscs and CEDs, but own a player for neither. |
| 10:56 |
jeff |
this is probably indicative of a larger problem. |
| 11:03 |
|
akilsdonk joined #evergreen |
| 11:16 |
kmlussier |
@love coffee |
| 11:16 |
pinesol_green |
kmlussier: But kmlussier already loves coffee! |
| 11:16 |
kmlussier |
@hate undrinkable coffee |
| 11:16 |
pinesol_green |
kmlussier: The operation succeeded. kmlussier hates undrinkable coffee. |
| 11:17 |
csharp |
@coffee kmlussier |
| 11:17 |
* pinesol_green |
brews and pours a cup of Kenya Peaberry Thika Gethumbwini, and sends it sliding down the bar to kmlussier |
| 11:18 |
kmlussier |
csharp: Thank you! I'm sure it will be better than the cup I just poured down the drain. |
| 11:25 |
kmlussier |
I apparently shouldn't be testing without my usual allotment of caffeine. I just set up a Vandelay match set that says "020 and 022 and 024 and 028" and then couldn't figure out why none of my incoming records were finding matches. |
| 11:33 |
|
jihpringle joined #evergreen |
| 11:35 |
kmlussier |
berick: I'm looking at bug 1350371. In the original description, you say Evergreen will "warn" the user if a duplicate PO name is used. The term "warn" makes me think a user can override the warning, but I don't see a way to override it and use the same PO name. |
| 11:35 |
pinesol_green |
Launchpad bug 1350371 in Evergreen "ACQ improved duplicate order detection" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1350371 - Assigned to Kathy Lussier (klussier) |
| 11:36 |
kmlussier |
Should I be able to override it and use the same PO name if I need to? Or is it working as designed? |
| 11:36 |
berick |
kmlussier: it should probably say "prevent" |
| 11:36 |
berick |
there's no way to override |
| 11:36 |
kmlussier |
berick: OK, good. Then it's behaving as designed. Thanks for the clarification. |
| 11:37 |
berick |
right back atcha |
| 11:43 |
kmlussier |
Nice! I like being able to add the PO name at PO creation time now and the alert that immediately pops up if you use a duplicate name. |
| 11:43 |
kmlussier |
I was expecting the alert to not show up until I hit submit. |
| 11:43 |
|
nhilton joined #evergreen |
| 11:44 |
berick |
yay |
| 11:50 |
dbs |
berick: for the TPAC discoverability enhancement bugs, do you want one omnibus release note bug to cover them all? they seem tiny enough that a separate release notes entry per bug probably doesn't make sense |
| 11:50 |
berick |
dbs: omnibus release note bug makes sense to me |
| 11:55 |
* dbs |
still has match_attr in vandelay.auto_overlay_bib_record() apparently because he was waiting for an actual bug fix |
| 12:00 |
dbs |
one less system with that problem now |
| 12:01 |
|
ericar_ joined #evergreen |
| 12:17 |
berick |
phasefx++ # timely LP entries |
| 12:17 |
|
akilsdonk joined #evergreen |
| 12:18 |
dbs |
Sounds like a cool feature |
| 12:19 |
phasefx |
you can thank kmlussier and friends for that one |
| 12:24 |
|
mtcarlson joined #evergreen |
| 12:33 |
dbs |
kmlussier++ |
| 12:33 |
dbs |
kmlussier's friends++ |
| 12:34 |
bshum |
@karma friends |
| 12:34 |
pinesol_green |
bshum: Karma for "friends" has been increased 1 time and decreased 0 times for a total karma of 1. |
| 12:34 |
bshum |
:D |
| 12:36 |
Dyrcona |
friends++ |
| 12:44 |
jeff |
coffee++ |
| 12:44 |
jeff |
friends++ |
| 13:03 |
kmlussier |
my friends++ |
| 13:03 |
kmlussier |
My friends don't get nearly enough credit for the work they do. :) |
| 13:04 |
kmlussier |
And let us not forget Georgia PINES, who partnered with us on that project. |
| 13:04 |
kmlussier |
pines++ |
| 13:08 |
dbs |
Without PINES, none of us would be here. pines++ |
| 13:14 |
kmlussier |
So true. I wonder where I would be if I weren't here. |
| 13:20 |
jeffdavis |
kmlussier: No doubt you would be elsewhere. |
| 13:25 |
kmlussier |
When should we move things from a 2.next to a 2.8 target? When we sign off on them? |
| 13:25 |
* dbs |
wasn't clear about the 2.next to 2.8 target thing either |
| 13:27 |
berick |
if it's (likely) going into 2.8, target 2.8-beta. |
| 13:27 |
berick |
if it's a ticket no one is working on or has no code, leave it in 2.next |
| 13:28 |
berick |
s/or has no code// |
| 13:29 |
berick |
need to follow up w/ bshum on renaming 2.next to a more generic feature request target |
| 13:30 |
berick |
hmm, or just drop 2.next and leave such things un-targeted |
| 13:31 |
kmlussier |
My recollection was that cdoe was required to get a 2.next milestone. But I could be misremembering. |
| 13:34 |
csharp |
PINES++ # my raison d'etre as well ;-) |
| 13:35 |
csharp |
Dyrcona++ # your "fix laserdisc records" script rox |
| 13:35 |
Dyrcona |
csharp: Thanks and you are welcome. |
| 13:36 |
Dyrcona |
pines++ |
| 13:36 |
Dyrcona |
I know where I'd be without PINES, but there would be no Evergreen there. |
| 13:36 |
Dyrcona |
@karma pines |
| 13:36 |
pinesol_green |
Dyrcona: Karma for "pines" has been increased 6 times and decreased 1 time for a total karma of 5. |
| 13:36 |
bshum |
kmlussier: berick: I'm not a fan of purely untargeted work, just because we've done that before and lots of bugs got lost in the void |
| 13:36 |
Dyrcona |
@karma PINES |
| 13:36 |
pinesol_green |
Dyrcona: Karma for "PINES" has been increased 6 times and decreased 1 time for a total karma of 5. |
| 13:36 |
bshum |
Till I pulled them out of the void every so often. |
| 13:36 |
Dyrcona |
Not case sensitive. I didn't think it was. |
| 13:37 |
bshum |
kmlussier: I think in the past, we've also targeted bugs with strong interest (with the expectation of code coming soon) to 2.next |
| 13:37 |
Dyrcona |
Targets can always be moved. |
| 13:38 |
* csharp |
is pretty sure he's the one who decremented pines karma ;-) |
| 13:41 |
bshum |
And yes, targets can always be moved. I think people just get tired of shuffling bugs endlessly. |
| 13:41 |
bshum |
By people, I really meant that *I* get tired of shuffling bugs endlessly, of course. |
| 13:41 |
bshum |
:) |
| 13:43 |
Dyrcona |
Well, we can dust off the old python script and see if we can get it to work again. |
| 13:45 |
bshum |
Also having a 2.next target was handy for "this is nice, but it's not going to be in 2.now" |
| 13:46 |
bshum |
But renaming it something more generic, sure. It's just a label for the concept :) |
| 13:47 |
berick |
would it make more sense to nominate for series only, then set milestones when the code is actually merged? you'd still know where it's supossed to go, and there'd be much less retargeting. |
| 13:48 |
berick |
since milestones for us are less about targeting and more about knowing when it actually got merged. |
| 13:50 |
* berick |
reminds the room of impending meeting |
| 13:52 |
bshum |
berick: Actually I use milestone targets to help guide me when I'm thinking through backport work for a given release series :) |
| 13:53 |
berick |
bshum: hmm. what does the milestone tell you that the series doesn't? |
| 13:53 |
bshum |
I find that clicking on a milestone and seeing what's there has always been easier than crafting the advanced search to find targets for a series, plus whatever words, etc. |
| 13:53 |
bshum |
But I'm lazy :) |
| 13:54 |
berick |
bshum: and that justifies the effort for constant retargeting? |
| 13:54 |
bshum |
berick: It's why I don't retarget often |
| 13:55 |
bshum |
Or assign too many milestones unless I know they're actually going to land. |
| 13:55 |
bshum |
But the conceptual effect of 2.next has worked to keep in mind all the new feature stuff that's waiting in the pipeline, while we work on other things. |
| 13:55 |
bshum |
For me anyways. |
| 13:56 |
bshum |
For bug fixes, 90% of the time, if I target a series, I'll also target a real milestone |
| 13:56 |
bshum |
Because it's likely that if I'm going to target it to a series, there's code to work with on it. |
| 13:56 |
bshum |
If there's no code, I'll likely just mark it as "confirmed" or "triaged" if I can replicate the issue or otherwise comment on it. |
| 13:56 |
bshum |
And leave it untargeted |
| 13:56 |
bshum |
Till there's actual code to work with |
| 13:57 |
bshum |
But I won't just target a series just because it affects it. |
| 13:57 |
bshum |
Because most of those bugs with no code ends up decaying anyways till a fix does come along. |
| 13:57 |
bshum |
At which point, we either discard the oldest targeted series (because we no longer support them) |
| 13:58 |
bshum |
Or update them to point at new series anyways, with the appropriate milestones. |
| 13:58 |
berick |
bshum: what's the difference between something targeting 2.next and something w/ no target? |
| 13:58 |
bshum |
berick: Something that's targeted for 2.next was chosen by someone. |
| 13:58 |
bshum |
Someone being a member of the bug team or developers |
| 13:59 |
bshum |
Untargeted bugs tend to be reports by community members on issues, or by people who just contribute something and then walk away. |
| 13:59 |
bshum |
Most devs when they contribute something also assign initial milestones nowadays. |
| 14:00 |
Dyrcona |
Or, who don't know they can target milestones. |
| 14:00 |
bshum |
Right, but that's less common. |
| 14:01 |
dbwells |
I would have expected 2.next to be renamed to 2.8-alpha/beta/whatever once 2.7 was released, but we missed that boat. |
| 14:01 |
bshum |
dbwells: I think that we did used to do that. But during 2.7 I talked with you about it and suggested we leave 2.next as a revolving door. |
| 14:01 |
bshum |
To avoid churn |
| 14:01 |
bshum |
And milestone shuffling. |
| 14:02 |
dbwells |
I recall that conversation now, but not the details or my thought process :) |
| 14:02 |
bshum |
Basically, new features should always target 2.next unless they're actually ready for merge with a numbered release. That way, if a new feature comes into existence on LP in between various dev cycles, it doesn't disappear or get lost forever. |
| 14:03 |
bshum |
And devs should periodically look at the 2.next list and pull stuff out to review for inclusion during the alpha/beta phase of each cycle. |
| 14:03 |
bshum |
Or others can champion to have their new feature added to a specific milestone, etc. |
| 14:04 |
bshum |
As we move into the post-beta/rc time, and new features continue to be created or added, they go to 2.next and are reviewed again after the release of the current primary focus series |
| 14:04 |
bshum |
That way, nothing stays untargeted and lost in the void |
| 14:05 |
berick |
thanks for talking it through, bshum |
| 14:05 |
kmlussier |
Well, here's my question. When berick says we have a deadline for targeting code for 2.8, does it need to be 2.8 or will 2.next be sufficient? |
| 14:05 |
berick |
good to understand the rationale for stuff |
| 14:05 |
berick |
kmlussier: are you referring to tomorrow's targeting deadline? |
| 14:06 |
kmlussier |
Yes |
| 14:06 |
berick |
for that, either works IMO. the point of that is more about getting stuff into LP |
| 14:07 |
bshum |
+1 |
| 14:07 |
berick |
avoiding last minute big feature surprises |
| 14:07 |
kmlussier |
Works for me! :) |
| 14:07 |
bshum |
And it's 2:07, sorry to have derailed the start of our meeting there. |
| 14:07 |
dbs |
Not derailed, just started early :_ |
| 14:07 |
berick |
exactly |
| 14:07 |
dbs |
:_ == slackjawed |
| 14:08 |
dbwells |
dbs: I wondered about that |
| 14:08 |
berick |
can we get a meeting DJ? |
| 14:08 |
berick |
or, MC |
| 14:08 |
* gmcharlt |
can spin some disks |
| 14:08 |
berick |
(sucka MC) |
| 14:08 |
berick |
gmcharlt++ |
| 14:08 |
gmcharlt |
one second |
| 14:09 |
gmcharlt |
#startmeeting Evergreen development meeting, 13 January 2014^W2015 |
| 14:09 |
pinesol_green |
Meeting started Tue Jan 13 14:09:04 2015 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:09 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 14:09 |
pinesol_green |
The meeting name has been set to 'evergreen_development_meeting__13_january_2014_w2015' |
| 14:09 |
gmcharlt |
#info Agenda is http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2015-01-13 |
| 14:09 |
gmcharlt |
#topic Introductions |
| 14:09 |
gmcharlt |
#info gmcharlt = Galen Charlton, ESI |
| 14:09 |
bshum |
#info bshum = Ben Shum, Bibliomation |
| 14:09 |
dbs |
#info dbs = Dan Scott, Laurentian University |
| 14:09 |
dbwells |
#info dbwells = Dan Wells, Hekman Library (Calvin College) |
| 14:09 |
berick |
#info berick = Bill Erickson, KCLS |
| 14:10 |
RoganH |
#info RoganH = Rogan Hamby, SCLENDS |
| 14:10 |
phasefx |
#info phasefx = Jason Etheridge, ESI |
| 14:10 |
jeffdavis |
#info jeffdavis = Jeff Davis, Sitka |
| 14:10 |
eeevil |
#info eeevil = Mike Rylander, ESI |
| 14:10 |
kmlussier |
#info kmlussier = Kathy Lussier, MassLNC |
| 14:10 |
remingtron |
#info remingtron = Remington Steed, Hekman Library (Calvin College) |
| 14:10 |
jeff |
#info jeff = Jeff Godin, Traverse Area District Library (TADL) |
| 14:12 |
gmcharlt |
ok |
| 14:12 |
gmcharlt |
#topic Updates - OpenSRF |
| 14:12 |
gmcharlt |
#info OpenSRF 2.4.0 released |
| 14:12 |
gmcharlt |
bshum++ |
| 14:12 |
gmcharlt |
#info current main target for OpenSRF 2.4.1 is adding a configuration option for using ports 80/443 for WS/WSS |
| 14:13 |
eeevil |
gmcharlt: is there a timeline that you know of? |
| 14:13 |
gmcharlt |
via a proxy put in front of the two Apache instances |
| 14:13 |
eeevil |
for the release, I mean |
| 14:13 |
bshum |
gmcharlt++ |
| 14:13 |
gmcharlt |
post-ALA and before 2.8 gets a beta |
| 14:14 |
eeevil |
k, thanks |
| 14:14 |
gmcharlt |
any other OpenSRF business? |
| 14:15 |
gmcharlt |
ok |
| 14:15 |
gmcharlt |
#topic Evergreen 2.8 updates |
| 14:15 |
gmcharlt |
berick? |
| 14:15 |
|
abowling joined #evergreen |
| 14:15 |
berick |
if you have any big features planned for 2.8, please get them into LP as soon as possible |
| 14:16 |
berick |
tomorrow is the official deadline, but.. just get them in ;) |
| 14:16 |
berick |
target 2.8-beta unless you are unsure it's actually going to happen |
| 14:17 |
berick |
and remember the beta merge freeze is Feb 20th. |
| 14:17 |
berick |
so we have just over a month for feature development |
| 14:17 |
berick |
and that's about it unless anyone has questions |
| 14:18 |
gmcharlt |
#info 14 January 2015 is the deadline for targeting new features slated for 2.8; use the 2.8-beta milestone |
| 14:19 |
gmcharlt |
ok, hearing no questions, moving on |
| 14:19 |
gmcharlt |
#topic New business - quality assurance |
| 14:19 |
gmcharlt |
kmlussier? |
| 14:20 |
kmlussier |
Sure. The folks at MassLNC were revisiting the QA report done a little over a year ago. |
| 14:21 |
kmlussier |
Since the report was issued, the community has come together to agree to do PGTap tests. But there are other recommendations that haven't been implemented yet. |
| 14:21 |
kmlussier |
So I thought it would be good to start a discussion among all of you to get a sense of what you think is needed to implement some of those other recommendations. |
| 14:22 |
jeff |
especially relevant since we're looking at a soon-to-be era where xulrunner is no more for Evergreen: ``there may be areas where improvements will be limited until Evergreen moves away from XULRunner'' |
| 14:23 |
kmlussier |
jeff: Are you thinking testing will become easier when we are off XULRunner? |
| 14:24 |
dbs |
Even on the PGTap side of things, we haven't really kept up with our commitment to add tests as we change the SQL |
| 14:24 |
jeff |
I was just quoting the part of the report that asserted (now I'm paraphrasing) that a move away from xulrunner would open the door for more improvements to QA and testing. |
| 14:25 |
bshum |
So, I admittedly haven't read the full report in awhile, but I'm not seeing any specific approaches being suggested. So the question on the floor is whether we would like to plan on finding some specifics and applying them towards say, the web client (as it's being created) |
| 14:25 |
kmlussier |
Is part of the issue the fact that we don't have people with the expertise and/or time to take charge of QA? |
| 14:26 |
eeevil |
kmlussier: I think that's The(tm) perpetual challenge ;) |
| 14:26 |
gmcharlt |
time in particular |
| 14:26 |
dbs |
But we kind of don't have the time to not do QA either |
| 14:27 |
gmcharlt |
also true |
| 14:27 |
kmlussier |
I also think testing goes beyond the client. For example, there were recommendations for a test suite to test for performance, for example. |
| 14:27 |
dbs |
Lacking at least one person with expertise + time, though, yeah, it's a problem. |
| 14:28 |
kmlussier |
So, I know there are people in the community who would be willing to put resources into bringing on a person to manage that process if it were needed. |
| 14:29 |
kmlussier |
First, I think it would be good to know if that is, indeed, what is needed. |
| 14:29 |
kmlussier |
Also, I didn't know if it would be worthwhile to look at other projects to see how QA is done. And, then, maybe pull the best from those projects to see what would work best for Evergreen. |
| 14:30 |
jeffdavis |
What would "bringing on a person" entail? |
| 14:30 |
berick |
well, there are some things we already have a good handle on (e.g. pgtap tests, perl unit tests, perl live tests). for those types of things, i think we just have to make ourselves do it. |
| 14:31 |
berick |
there's a lot we could do we're just not doing. |
| 14:31 |
dbs |
amen |
| 14:31 |
kmlussier |
berick: Does everyone contributing code have a good handle on that? |
| 14:31 |
berick |
having someone whose job it is to think about it for big picture stuff would be great, but we shouldn't let that slow us down |
| 14:32 |
jeff |
berick: during sprint 1 of the web client, you had some unit tests in place (correct me if i'm wrong) -- could you hazard a guess as to what percentage of interfaces have unit tests? |
| 14:32 |
berick |
kmlussier: well, no, because we don't do it regularly enough for everyone of have templates to work from |
| 14:32 |
gmcharlt |
a somewhat stricter attitude about requiring pgTap tests and Perl unit tests to accompany patches would be a step forward for the 2.8 cycle |
| 14:32 |
berick |
jeff: those unit tests were almost entirely focused on the services (i.e. the stuff under the interfaces) |
| 14:33 |
berick |
jeff: so, very little UI coverage |
| 14:33 |
berick |
gmcharlt: agreed |
| 14:34 |
jeff |
berick: got it. thanks. |
| 14:35 |
phasefx |
jfyi, one notion I encountered was to not focus on testing "services" through the UI, but the test the UI itself (widgets, etc.) if testing the UI, and test the services more closely to where they live if testing the services |
| 14:35 |
kmlussier |
I think my group would be in favor of stricter requirements for tests and whatever else you can do now. |
| 14:35 |
gmcharlt |
as far as I'm concerned personally, providing pgTap + perl tests for the stuff I'm slated to do for 2.8 is easy enough |
| 14:36 |
kmlussier |
But if the developers, as a group, told me, "we really need somebody to manage this process," I would do what I could to make that happen. |
| 14:37 |
dbs |
I imagine the developers are trying to imagine how such a person dropped into our midst could actually manage the process. |
| 14:37 |
kmlussier |
I'm mostly concerned that there is still more testing beyond pgTap and perl tests that we need to be doing. |
| 14:37 |
dbs |
Buy-in would be tough. |
| 14:38 |
jeff |
I consider myself a novice with regard to Perl tests, and moreso with regard to pgTap tests. I'd be willing to extract knowledge and experience from others and formulate something of a reference / set of guidelines for contributors in the hope that it would help myself and others include appropriate tests in contributions. |
| 14:38 |
gmcharlt |
on the other hand -- somebody who had an explicit committment to review patches (and who could come up the speed) might be an easier dose of medicine, as it were |
| 14:38 |
kmlussier |
Yes, well, that's why I'm raising the questions here. |
| 14:39 |
* dbs |
would like to automatically test the TPAC for basic accessibility compliance, ensuring RDFa comes out right, ensuring data is displayed as expected (which would be hella useful if we move misc_util.tt2 into Perl module land) |
| 14:39 |
jeff |
dbs++ good job putting words to what I was thinking ("dropped into our midst" comment above) |
| 14:40 |
kmlussier |
Well, any new developer is essentially "dropped into our midst," right? |
| 14:40 |
berick |
jeff: i'd be happy to help review/edit any such guidlines |
| 14:40 |
dbs |
Unfortunately most of those tests would require python for RDFLib and I'm not keen on introducing more dependencies |
| 14:40 |
gmcharlt |
dbs: does that translate to "you are willing to help set up such testing"? I'd be happy to collaborate with you on that |
| 14:41 |
jeff |
berick++ sounds good. |
| 14:41 |
dbs |
kmlussier: yes, but the mindset is often such that a new developer == "yay they're helping build this thing" vs "this person is getting in the way" |
| 14:41 |
gmcharlt |
vs "this stranger is TELLING US WHAT TO DO. OH NOES!" |
| 14:42 |
dbs |
/ "where do they get off..." |
| 14:42 |
kmlussier |
Yes, I understand. |
| 14:42 |
kmlussier |
At the same time, I haven't seen any current developers say they want to take charge of QA, and I think it's more from lack of time than lack of desire. |
| 14:42 |
dbs |
gmcharlt: yeah, I guess basically it's a glorified curl / string processing thing, so yeah |
| 14:42 |
kmlussier |
Overall, I think that's what's needed. Somebody who is willing to take charge. |
| 14:43 |
berick |
i would welcome someone whose job it was to research and present ideas, proofs-of-concept, etc. on QA stuff. |
| 14:43 |
berick |
"manage" and "take charge" may not be the right words |
| 14:43 |
berick |
"drive" maybe |
| 14:43 |
jeff |
berick: as 2.8 RM how do you feel about gmcharlt's proposal of "a somewhat stricter attitude about requiring" tests? |
| 14:43 |
dbs |
"Hey, look at what you can do with a few lines of additional code" |
| 14:43 |
kmlussier |
Yes, "drive" is a good word. :) As gmcharlt said, somebody with an explicit commitment. |
| 14:44 |
gmcharlt |
berick: and "review patches"... I really think it does need to be grounded |
| 14:44 |
berick |
jeff: +1 from me for bumping to strictness level 2 |
| 14:44 |
berick |
gmcharlt: ah, yes, that would ideal |
| 14:45 |
jeff |
gmcharlt: am i correct in thinking that koha has an explicit "QA" signoff? Is that a mostly automatic (tests passed!) signoff, or is that a human signing off with a specific eye toward QA? |
| 14:46 |
jeff |
(deja vu -- i may have asked this question before) |
| 14:46 |
gmcharlt |
jeff: the Koha process seeks two signoffs |
| 14:46 |
gmcharlt |
1st signoff is from essentially anybody who can install the patch and run it through its paces |
| 14:47 |
dbs |
#link One accessibility checking API: http://wave.webaim.org/api/ (costs $$$ but it's an option) |
| 14:47 |
gmcharlt |
the 2nd, QA signoff is based on an inspection by a human member of the QA team + the patches passing a set of extra, mostly static source-code level tests |
| 14:47 |
berick |
as far as 2.8 goes, we'll need some guidelines for building tests, what the minimal requirements are. I can build/collaborate on that. i'll obviously need input, though. |
| 14:47 |
berick |
and since it's late in the game, we'll have to be pretty forgiving |
| 14:48 |
jeff |
sure. nobody's proposing FESTIVITY^WSTRICTNESS LEVEL 4. |
| 14:49 |
gmcharlt |
so we have, to sum up, the following concrete suggestions at th emoment |
| 14:49 |
gmcharlt |
1. incrementing the strictness level |
| 14:49 |
gmcharlt |
2. berick et al writing up some guidelines and templates for pgTAP and perl unit tests |
| 14:49 |
gmcharlt |
3. dbs and galen putting together some automatic testing of TPAC and RDFa output |
| 14:50 |
gmcharlt |
and less concretely, some fuzzy input on desiderata for a "QA person" |
| 14:50 |
dbs |
#link another accessibility checking API: https://github.com/inclusive-design/AChecker (GPL v2) |
| 14:50 |
* gmcharlt |
has used AChecker in the past, FWIW |
| 14:51 |
kmlussier |
gmcharlt: Would it be helpful if someone (I can volunteer) do an environmental scan of other projects and who they handle these issues? |
| 14:51 |
gmcharlt |
kmlussier: yes - in particular, if such a scan also looks for people with track records in doing this sort of work |
| 14:52 |
gmcharlt |
not just the QA, but the introducdtion of process improvement |
| 14:52 |
kmlussier |
OK, I can do that, but I welcome any help if anyone wants to work with me on it. :) |
| 14:52 |
jeff |
kmlussier: to clarify-- did you mean "how they handle these issues", or were you focused on a "who"? |
| 14:52 |
gmcharlt |
kmlussier: I haz thoughts on the matter and would be interested in working with you on it |
| 14:53 |
kmlussier |
jeff: The who is part of it, but the overall process too. |
| 14:53 |
kmlussier |
gmcharlt: Thanks! |
| 14:55 |
gmcharlt |
so, just to double-check -- are folks (particularly committers) OK with stricter enforcement of providing pgTAP & perl unit tests for the 2.8 cycle? |
| 14:55 |
eeevil |
may I as that followups happen on the -dev list? (rather than -general, not to exclude folks, but to avoid pulling in -dev help) |
| 14:55 |
eeevil |
the kmlussier + gmcharlt + dbs + berick + others followups, I mean |
| 14:56 |
kmlussier |
eeevil: That's fine with me |
| 14:56 |
gmcharlt |
agreed |
| 14:56 |
jeff |
It will make some things harder, but those things may well be the things that would most benefit from unit tests. |
| 14:57 |
jeff |
(or pgTAP tests) |
| 14:57 |
eeevil |
gmcharlt: for my part (re agreement), yes, where applicable and reasonable (that is, not useless for lack of context), stricter enforcement of tests |
| 14:57 |
* eeevil |
does not plan to write tests that require a mock env that emulates all of Evergreen ... fwiw ;) |
| 14:57 |
gmcharlt |
eeevil: indeed - I can point to some examples in recent memory of cases where some testing-for-the-sake-of-following-the-rules was in play |
| 14:58 |
jeff |
eeevil: I don't think that any of our employers have enough time that tests for the sole sake of tests will be a common thing. :-) |
| 14:58 |
phasefx |
are we excluding or including integration tests here against live test systems? |
| 14:58 |
gmcharlt |
but I will emphasize that at the moment, Evergreen is in no danger of that! |
| 14:58 |
eeevil |
gmcharlt: fair ;) |
| 14:58 |
berick |
phasefx: I was hoping to encourage the use of live tests for changes that can't be tested in a vacuum, if that's what you're asking |
| 14:58 |
gmcharlt |
OK, I'm going to summarize, then move on to the next agenda item |
| 14:59 |
phasefx |
berick: sounds good to me, and I just saw eeevil's desire not to build huge mock environments :) |
| 14:59 |
gmcharlt |
#item There is general agreement that for the 2.8 cycle, we'll be stricter about requiring relevant pgTAP & perl unit tests |
| 14:59 |
gmcharlt |
#info There is general agreement that for the 2.8 cycle, we'll be stricter about requiring relevant pgTAP & perl unit tests |
| 14:59 |
gmcharlt |
#info berick will write some guidelines on writing Perl and pgTAP tests |
| 15:00 |
gmcharlt |
#info dbs and gmcharlt will work on automating accessibility and RDFa tests of TPAC |
| 15:00 |
jeff |
berick: see what i did there, how that turned from you reviewing/editing to writing those from scratch? ;-) |
| 15:00 |
gmcharlt |
#info kmlussier will do an environement scan of QA practices and experts in other project, with help from gmcharlt and others |
| 15:00 |
* jeff |
ducks |
| 15:01 |
* gmcharlt |
creates a LP project for filing bug reports against the meeting minutes ;) |
| 15:01 |
gmcharlt |
#topic Overdrive circulation API code |
| 15:01 |
gmcharlt |
#link http://markmail.org/message/cgcrmqdz4nrm5erv |
| 15:01 |
berick |
jeff: you must teach me this power |
| 15:02 |
jeff |
sitka++ |
| 15:02 |
jeffdavis |
As that linked email says, we have working code to make use of Overdrive's API in the Evergreen OPAC. |
| 15:03 |
jeffdavis |
We'd like this to be adopted by the EG community, so I'm interested in how to help make that happen. |
| 15:04 |
gmcharlt |
well, there are various levels |
| 15:04 |
gmcharlt |
one approach that woudl require very little work on your part is to set it up as a contrib whose home repository lives on git.evergreen-ils.org |
| 15:05 |
gmcharlt |
and supply some documentation |
| 15:05 |
gmcharlt |
folding it into Evergreen core would, at minimum, require more work |
| 15:05 |
jeff |
I can see this starting as a contrib and potentially becoming core or inspiring core. |
| 15:06 |
kmlussier |
Would it only be acceptable if there were no new dependencies required? |
| 15:06 |
dbs |
Adding CoffeeScript + Node + jQuery knowledge requirements (for bug-fixing/enhancements) & install/config/maintenance (for just using) is certainly not enticing |
| 15:06 |
jeff |
I don't think we have a strong rule about "no new dependencies". |
| 15:06 |
dbs |
(not to em, anyway) |
| 15:06 |
jeffdavis |
(not to me either, fwiw) |
| 15:06 |
dbs |
s/em/me/ |
| 15:07 |
dbs |
The last new dependency was Ruby for EDI, no? |
| 15:07 |
jeff |
But there are approaches that can be taken to services like OverDrive and OneClickdigital that don't involve as many additional dependencies. |
| 15:08 |
jeff |
jeffdavis: do you know if the code as it exists supports libraries with different "OverDrive Advantage" subscriptions within an (OverDrive) consortium, or supports more than one specific method of patron authentication? |
| 15:08 |
berick |
dbs: yeah, but i'm actively fighting to kill the ruby stuff. |
| 15:08 |
dbs |
berick: that's what I mean :) |
| 15:08 |
jeff |
Those would be the first things that came to mind when looking over the code in terms of "would be nice to have before consideration of incorportating it into Evergreen" |
| 15:08 |
dbs |
And trading XUL for AngularJS |
| 15:09 |
jeff |
(please don't take either of those as criticism, by the way) |
| 15:09 |
gmcharlt |
berick++ # although to be clear to any Rubyists watching, Ruby per se isn't necessarily a problem; the problem is more "a tiny bit of one language does not mix well in a code base that is predominantly written in another" |
| 15:09 |
jeffdavis |
jeff: It can be made to support multiple OD accounts - that is actually my next task vis-a-vis the project. I think making it support multiple methods of patron auth would take more work. |
| 15:09 |
dbs |
Is the Overgreen code (I love that neologism) GPL v2 compliant, too? |
| 15:09 |
csharp |
overgreen++ |
| 15:09 |
jeffdavis |
I've been calling it OD API, but Overgreen works :) |
| 15:09 |
eeevil |
jeffdavis: 2 questions (since I haven't looked at the code yet) 1) is the coffeescript yours or overdrive's? and if the latter, could the coffeescript be compiled down to a blob we could include in the release, instead of requiring new deps? |
| 15:10 |
jeff |
dbs: the repo claims MIT license, and there is no OverDrive code to license, just an API. |
| 15:10 |
berick |
gmcharlt: yes, of course. i'm fighting the added dependency, not the language. |
| 15:10 |
jeff |
s/repo/sitka repo/ |
| 15:10 |
eeevil |
(a la dojo) |
| 15:11 |
jeff |
eeevil: the coffeescript is sitka's, and requires nodejs at build time. |
| 15:11 |
dbs |
jeff: yeah, I saw the MIT license, but also saw it came after the bulk of the work was done; wanted to ensure it was applied cleanly |
| 15:11 |
jeff |
eeevil: so no, it couldn't be reduced to a blob in the repo, but it could live externally as contrib and evergreen could contain hooks that would tie into the blob built from contrib if present. |
| 15:11 |
eeevil |
jeffdavis: could post-build code be pulled in to get something in for 2.8? |
| 15:11 |
eeevil |
oh, ok |
| 15:12 |
|
mrpeters joined #evergreen |
| 15:12 |
jeffdavis |
Either of those approaches could work really. |
| 15:12 |
jeffdavis |
I think jeff's suggestion is probably a bit better for now, though. |
| 15:13 |
gmcharlt |
one thing that does bother me about the implementation is that it seems a bit delicate with respect to changes to the TPAC templates |
| 15:13 |
jeffdavis |
dbs: The MIT license was added to the source relatively late, but it was originally marked as MIT-licensed when our developer published it on Google Code. |
| 15:13 |
jeff |
jeffdavis: with regard to "Steven Chan making 32 commits and then Jeff Davis adding a LICENSE.txt and Copyright statement"... can you clarify for purposes of copyright/license what the status of the code is? I don't even know enough about Canadian copyright law to ask the right question there. |
| 15:14 |
gmcharlt |
e.g., bits like this: http://paste.lisp.org/display/145214 |
| 15:14 |
jeffdavis |
Steven Chan wrote almost all of the code on contract for Sitka. As mentioned, he had licensed it under MIT but the license wasn't included in his source. I added it once I inherited ownership of the project a few months ago. |
| 15:14 |
jeffdavis |
s/added it/added an explicit MIT license in the source/ |
| 15:15 |
gmcharlt |
jeffdavis: do you know if it was a work-for-hire for Sitka? |
| 15:15 |
RoganH |
jeffdavis: was it licensed as MIT as per contract with SITKA? |
| 15:15 |
jeffdavis |
gmcharlt: yes, my understanding is that it was work-for-hire for Sitka. |
| 15:15 |
dbs |
In Canada, work for hire doesn't apply, IIRC |
| 15:16 |
jeffdavis |
dbs: Steven's contract would have assigned copyright in his work for Sitka to Sitka, though. |
| 15:16 |
RoganH |
dbs: you are correct |
| 15:16 |
jeffdavis |
At least, that was my understanding when I asked about it before adding the license. |
| 15:17 |
jeffdavis |
I'm happy to seek any required clarification. |
| 15:17 |
jeff |
would having Steven Chan post confirmation of that to open-ils-dev be sufficient to clear things up for everyone? |
| 15:17 |
gmcharlt |
let's draw the licensing discusison to a close -- I thnk Sitka should clarify the copyright and license status, but it is reasonable to assume that any loose ends can be tied up |
| 15:18 |
* dbs |
agrees with gmcharlt |
| 15:19 |
jeff |
Include in 2.8 with some light work, and known missing aspects, or Not included in 2.8, but an exciting/promising optional contrib/add-on for those interested? |
| 15:19 |
jeff |
or are we not looking for a decision on that at this point, and just taking a moment to discuss without action? |
| 15:19 |
gmcharlt |
I don't think we need to finalize a decision now -- I think it would suffice for jeffdavis to file a 2.8-beta LP for now |
| 15:20 |
jeff |
(and knowing that features don't go in/out based on developer meeting discussion alone) |
| 15:20 |
jeffdavis |
I'll do that, and set up this project as a contrib on git.evergreen-ils.org as well. |
| 15:20 |
dbs |
jeffdavis++ |
| 15:20 |
dbs |
sitka++ |
| 15:20 |
bshum |
jeffdavis++ sitka++ |
| 15:20 |
kmlussier |
jeffdavis++ sitka++ |
| 15:20 |
gmcharlt |
and finally |
| 15:20 |
jeffdavis |
I should explicitly say that Sitka would prefer not to own this project long-term, so hopefully either the community can take it on or make use of it to develop API integration that works better. |
| 15:21 |
gmcharlt |
#topic Negative blances / billing improvements |
| 15:21 |
gmcharlt |
#link https://bugs.launchpad.net/evergreen/+bug/1198465 |
| 15:21 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 14, heat: 66) [Wishlist,Confirmed] |
| 15:21 |
dbwells |
I'm already late for another meeting, so I'll make this quick. |
| 15:21 |
dbwells |
Basically, I'm just fishing for help in testing some or all of the billing changes which have grown on that bug. |
| 15:22 |
dbwells |
As I stated in the agenda, I think separating out the root-level stuff and getting that tested/committed first would be a good strategy. Any takers for testing? |
| 15:22 |
berick |
dbwells: +1 to the idea of breaking out cstore billing to its own LP. I would help poke at that. |
| 15:22 |
jeff |
I'm interested in testing. |
| 15:22 |
berick |
it's much more digestable... |
| 15:22 |
kmlussier |
I'm interested in testing too. |
| 15:22 |
dbwells |
sweet, thanks all |
| 15:22 |
jeff |
I hate to ask, but... are there tests in the root-level stuff at this point in time? |
| 15:23 |
dbwells |
I've been working this morning on getting the cstore stuff separated, it wasn't too bad. |
| 15:23 |
dbwells |
jeff: Only in that it doesn't (or mightn't) break the existing billing tests. |
| 15:24 |
dbwells |
At least that portion isn't meant to do anything new. Not that we couldn't always use more tests, of course. |
| 15:24 |
jeff |
In some ways, that's enough! Always nice when there are existing relevant tests. :-) |
| 15:24 |
gmcharlt |
#action dbwells will separate the cstore billing code into a separate bug; jeff and berick will help with testing |
| 15:25 |
gmcharlt |
and I suggest follow-up to open-ils-dev |
| 15:25 |
dbwells |
I am out for now. Thanks again to those who volunteered; expect to be bugged by me soon. |
| 15:25 |
jeff |
dbwells++ |
| 15:26 |
kmlussier |
dbwells++ |
| 15:26 |
gmcharlt |
so, since we're at nearly 1:20 - I will give folks 2.5 seconds to suggest last-minute topics |
| 15:26 |
* gmcharlt |
drops the portcullis |
| 15:26 |
bshum |
dbwells++ |
| 15:26 |
gmcharlt |
#endmeeting |
| 15:26 |
pinesol_green |
Meeting ended Tue Jan 13 15:26:25 2015 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:26 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-01-13-14.09.html |
| 15:26 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-01-13-14.09.txt |
| 15:26 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-01-13-14.09.log.html |
| 15:26 |
bshum |
gmcharlt++ |
| 15:26 |
berick |
gmcharlt++ |
| 15:27 |
jeff |
gmcharlt++ |
| 15:27 |
jeffdavis |
gmcharlt++ |
| 15:27 |
eeevil |
gmcharlt++ |
| 15:27 |
kmlussier |
gmcharlt++ |
| 15:27 |
dbwells |
gmcharlt++ |
| 15:29 |
jeffdavis |
So, how do I go about getting a new contrib repo added to git.evergreen-ils.org? :) |
| 15:30 |
gmcharlt |
jeffdavis: contrib/sitka OK as a name for it? |
| 15:30 |
gmcharlt |
and anybody besides you who should be allowed to push to it? |
| 15:30 |
jeffdavis |
gmcharlt: Would it be better to specify the project rather than Sitka (e.g. contrib/overdrive-evergreen-opac or something)? |
| 15:31 |
gmcharlt |
that's also fine |
| 15:31 |
* gmcharlt |
will have to resiist the tempation to name it contrib/overgreen |
| 15:31 |
jeffdavis |
:) |
| 15:32 |
kmlussier |
+1 to overgree :) |
| 15:32 |
jeffdavis |
I'm the only one at Sitka pushing to our local repo currently, so no one specific to add. If other EG developers want that ability that's fine by me. |
| 15:32 |
jcamins |
I, for one, welcome our new open source overlords. |
| 15:33 |
jeff |
jcamins: their reign shall be for twelve months or 26 checkouts, whichever is shorter. |
| 15:34 |
gmcharlt |
jeff++ |
| 15:36 |
gmcharlt |
jeffdavis: ok, contrib/overdrive-eg-opac now exists, and you can push to it |
| 15:45 |
kmlussier |
@dessert |
| 15:45 |
* pinesol_green |
grabs some pineapple chocolate things from New Zealand for kmlussier |
| 15:45 |
kmlussier |
Not exactly what I was looking for. |
| 15:46 |
jeffdavis |
gmcharlt++ # thanks! |
| 15:46 |
jeffdavis |
I've pushed the current Overdrive master branch to that contrib repo. |
| 15:50 |
kmlussier |
@dessert search brownie |
| 15:50 |
pinesol_green |
kmlussier: 1 found: #6: "Supreme Brownie Sundae" |
| 15:51 |
* gmcharlt |
pounces on the supreme brownie sundae |
| 15:52 |
* berick |
chuckles at 'pineapple chocolate things' |
| 15:52 |
berick |
not sure if really a thing or someone got lazy |
| 15:53 |
kmlussier |
berick: It's a thing that has a real name. |
| 15:54 |
kmlussier |
That is, a name that is not "pineapple chocolate things." |
| 15:54 |
kmlussier |
Maybe Pineapple Lumps? http://en.wikipedia.org/wiki/Pineapple_Lumps |
| 15:56 |
berick |
having a hard time imagining that flavor combo |
| 15:57 |
kmlussier |
berick: They're quite tasty. |
| 15:58 |
Dyrcona |
berick: https://www.youtube.com/watch?v=hpj2oVJhYjM |
| 16:00 |
bshum |
dbs: Question on the relators.tt2 |
| 16:00 |
bshum |
At the end of the generated block, there's an extra comma there after the wst entry |
| 16:00 |
berick |
Dyrcona++ |
| 16:00 |
bshum |
Is that "normal"? |
| 16:01 |
bshum |
Actually as I look at the original file, there's a comma at the end of that one too, maybe it doesn't do anything weird. |
| 16:01 |
bshum |
Just looked strange for a moment to my eye |
| 16:12 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1074096: Remove Bib Call Number Search - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=73f5327> |
| 16:12 |
pinesol_green |
[evergreen|Dan Scott] LP#1407507: Update relator codes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1cfbba3> |
| 16:12 |
|
julialima_ left #evergreen |
| 16:13 |
kmlussier |
Yay! |
| 16:13 |
bshum |
berick: Any last additions for https://bugs.launchpad.net/evergreen/+bug/1392759 ? I think it looks fine enough to push ahead. |
| 16:13 |
pinesol_green |
Launchpad bug 1392759 in Evergreen "Developer/Packager Makefile.install targets" (affected: 1, heat: 6) [Wishlist,Triaged] |
| 16:14 |
* bshum |
is going to make the tiny alteration for ubuntu-trusty to get rid of that last 'make' in there. |
| 16:15 |
berick |
bshum: nothing else from me |
| 16:16 |
bshum |
Cool, cool |
| 16:16 |
pinesol_green |
[evergreen|Bill Erickson] LP#1392759 developer/packager Makefile.install targets - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=249ea3b> |
| 16:16 |
pinesol_green |
[evergreen|Bill Erickson] LP#1392759 dev/packager Makefile.install additions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=239525e> |
| 16:16 |
pinesol_green |
[evergreen|Bill Erickson] LP#1392759 dev/pack makefile.install repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e6ce8fe> |
| 16:16 |
pinesol_green |
[evergreen|Bill Erickson] LP#1392759 Add 'bzr' to 'packager' targets - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=615c79d> |
| 16:17 |
berick |
bshum++ |
| 16:19 |
Dyrcona |
While the meeting was going on, we had another incident with the load on the server going over 100, etc. |
| 16:19 |
Dyrcona |
On the plus side, I can say that the edit to /etc/pam.d/su suggested by several blog posts works. |
| 16:20 |
Dyrcona |
ejabberd can now open 65535 files. |
| 16:20 |
dbs |
bshum++ |
| 16:21 |
* dbs |
finds that a chunk of TPAC code from 2012 for enabling a "detailed results view" by default slipped in at some point, but not the complete set of code required for that |
| 16:21 |
bshum |
dbs: For lack of a better place yet, I did put the relator_map note on berick's new http://wiki.evergreen-ils.org/doku.php?id=dev:release_process:evergreen:2.8#other_notes |
| 16:22 |
jeff |
Dyrcona: hooray |
| 16:22 |
bshum |
We'll find a suitable place to slot that in for future releases too. |
| 16:22 |
dbs |
err, 2013 |
| 16:22 |
dbs |
bshum++ |
| 16:22 |
dbs |
commit 8068d3389 was the culprit |
| 16:22 |
pinesol_green |
[evergreen|Dan Scott] Just use a format label in results + pubdate - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8068d33> |
| 16:23 |
* dbs |
will file a bug targeted for 2.8 to add the "show_more_details" config.tt2 parameter |
| 16:23 |
bshum |
Nooo netsplits?! |
| 16:26 |
dbs |
not fer me |
| 16:27 |
bshum |
It was just some global notice I just got.... maybe it's nothing :) |
| 16:27 |
* bshum |
loves https://bugs.launchpad.net/evergreen/+bug/1409844 |
| 16:27 |
pinesol_green |
Launchpad bug 1409844 in Evergreen "TPAC: Towards more meaningful, contextual page titles" (affected: 1, heat: 6) [Undecided,New] |
| 16:28 |
bshum |
dbs++ |
| 16:28 |
bshum |
It works for me, I'll push a signoff, but am holding off merging till the requisite 1 week watch period is over. |
| 16:31 |
dbs |
bshum: sounds great to me |
| 16:32 |
|
mrpeters left #evergreen |
| 16:34 |
|
jcamins joined #evergreen |
| 16:34 |
|
paxed joined #evergreen |
| 16:34 |
|
mnsri_away joined #evergreen |
| 16:34 |
|
rashma joined #evergreen |
| 16:34 |
|
pmurray joined #evergreen |
| 16:34 |
|
b_bonner joined #evergreen |
| 16:34 |
|
tsbere joined #evergreen |
| 16:34 |
|
dcook__ joined #evergreen |
| 16:34 |
|
mtate joined #evergreen |
| 16:34 |
|
eeevil joined #evergreen |
| 16:34 |
|
phasefx joined #evergreen |
| 16:34 |
|
Shae joined #evergreen |
| 16:34 |
|
nhilton joined #evergreen |
| 16:34 |
|
gmcharlt joined #evergreen |
| 16:34 |
|
pinesol_green joined #evergreen |
| 16:37 |
|
Dyrcona joined #evergreen |
| 16:37 |
|
gsams joined #evergreen |
| 16:39 |
|
RoganH joined #evergreen |
| 16:39 |
jeffdavis |
I've created bug 1410537 - can someone with the necessary perms target it for 2.8-beta? |
| 16:39 |
pinesol_green |
Launchpad bug 1410537 in Evergreen "Overdrive API integration" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1410537 |
| 16:39 |
bshum |
jeffdavis: Sure. |
| 16:40 |
|
dreuther_ joined #evergreen |
| 16:40 |
|
rangi joined #evergreen |
| 16:40 |
|
_bott_ joined #evergreen |
| 16:40 |
|
ldw joined #evergreen |
| 16:40 |
|
pastebot joined #evergreen |
| 16:40 |
|
egbuilder joined #evergreen |
| 16:40 |
|
csharp joined #evergreen |
| 16:40 |
bshum |
All set. |
| 16:41 |
jeffdavis |
bshum++ # thank you! |
| 16:43 |
|
jihpringle joined #evergreen |
| 16:43 |
|
chatley joined #evergreen |
| 16:43 |
|
finnx joined #evergreen |
| 16:44 |
Dyrcona |
Grr... What are they running? ejabberd? |
| 16:45 |
jeffdavis |
13:22 [freenode] -mquin(~mquin freenode/staff/mquin)- [Global Notice] We are about to start rehubbing the network ahead of planned maintenance work. This will cause some netsplits, but should be completed shortly. |
| 16:46 |
Dyrcona |
Still doesn't answer my question. :) |
| 16:48 |
|
vlewis joined #evergreen |
| 16:49 |
jeffdavis |
true. |
| 16:50 |
|
graced joined #evergreen |
| 16:50 |
|
bshum joined #evergreen |
| 16:50 |
|
kmlussier joined #evergreen |
| 16:50 |
|
mceraso joined #evergreen |
| 16:50 |
|
dbs joined #evergreen |
| 16:50 |
|
eby joined #evergreen |
| 16:50 |
|
DPearl1 joined #evergreen |
| 16:50 |
|
bradl_ joined #evergreen |
| 16:53 |
|
Stompro joined #evergreen |
| 16:53 |
|
phasefx_ joined #evergreen |
| 16:53 |
|
mmorgan joined #evergreen |
| 16:53 |
|
dbwells joined #evergreen |
| 16:53 |
|
mtcarlson joined #evergreen |
| 16:53 |
|
jeff joined #evergreen |
| 16:54 |
|
jeffdavis joined #evergreen |
| 16:54 |
|
book` joined #evergreen |
| 16:55 |
Dyrcona |
Well, I'm taking off anyway. |
| 16:57 |
|
kitteh_ joined #evergreen |
| 16:59 |
|
RBecker joined #evergreen |
| 16:59 |
|
remingtron joined #evergreen |
| 16:59 |
|
artunit joined #evergreen |
| 16:59 |
|
dkyle joined #evergreen |
| 16:59 |
|
mtj_- joined #evergreen |
| 16:59 |
|
edoceo joined #evergreen |
| 16:59 |
|
jeff_ joined #evergreen |
| 16:59 |
|
berick joined #evergreen |
| 16:59 |
|
Bmagic joined #evergreen |
| 16:59 |
bshum |
Calling 0903 |
| 17:03 |
pinesol_green |
Showing latest 5 of 6 commits to Evergreen... |
| 17:03 |
pinesol_green |
[evergreen|Jason Stephenson] LP#980296: Add void of lost processing fee on claims returned. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=806ecaa> |
| 17:03 |
pinesol_green |
[evergreen|Jason Stephenson] LP#980296: Update void on claims returned for longoverdue status. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fc361aa> |
| 17:03 |
pinesol_green |
[evergreen|Jason Stephenson] LP#980296: pgtap tests for the void on claims returned org settings. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a98eac1> |
| 17:03 |
pinesol_green |
[evergreen|Kathy Lussier] LP#980296: Release notes entry for voiding lost on Claims Return - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=db91d15> |
| 17:03 |
pinesol_green |
[evergreen|Ben Shum] LP#980296: Stamping upgrade script for void lost on claims returned, etc. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e75501d> |
| 17:06 |
|
graced joined #evergreen |
| 17:06 |
|
bshum joined #evergreen |
| 17:06 |
|
kmlussier joined #evergreen |
| 17:06 |
|
mceraso joined #evergreen |
| 17:06 |
|
dbs joined #evergreen |
| 17:06 |
|
eby joined #evergreen |
| 17:06 |
|
DPearl1 joined #evergreen |
| 17:06 |
|
bradl_ joined #evergreen |
| 17:14 |
|
mmorgan left #evergreen |
| 17:17 |
eeevil |
berick: since you've been fiddling with make bits recently, do you know of a way to keep make from dereferencing every freaking symlink between / and a file it's compiling? |
| 17:17 |
eeevil |
IOW, "just use the path I gave you, stop trying to be so clever!" |
| 17:19 |
berick |
hm, i'm not familiar with that problem. |
| 17:20 |
eeevil |
it's probably only a problem for me, TBH, but it's a painful problem |
| 17:21 |
bshum |
Fancy |
| 17:21 |
bshum |
I got the IRC logs to link to bug numbers in LP based on the git commit messages |
| 17:21 |
bshum |
Like for: http://irc.evergreen-ils.org/evergreen/2015-01-13#i_149761 |
| 17:22 |
bshum |
I noticed it was doing it for RT links back to rt.perl.org, so I changed it to LP and asked it to link any 2-7 digit string to LP. We'll see how that goes... |
| 17:22 |
* bshum |
should probably make that only match on 5-7 digit strings |
| 17:22 |
bshum |
Well, maybe 6-7 |
| 17:22 |
eeevil |
berick: if you have a symlink at, say, ~/source/eg pointing to one of several tarball extracts, the build system under make's control will use (the equiv of) bash's readlink to dereference the path and go there |
| 17:22 |
bshum |
5 and we'd have all these zip codes when people do weather... |
| 17:23 |
eeevil |
and I so don't want it to do that :) |
| 17:23 |
eeevil |
(so `pwd` thinks its somewhere under /home/miker/source/eg/... and not the "real" location) |
| 17:24 |
bshum |
Aha, it only does that on #prefixed numbers. That's nice :) |
| 17:24 |
* bshum |
should learn more regex |
| 17:28 |
berick |
eeevil: no idea :( sorry |
| 17:29 |
eeevil |
np, thanks |
| 17:33 |
|
eby joined #evergreen |
| 17:42 |
|
nhilton_ joined #evergreen |
| 17:44 |
|
vlewis_ joined #evergreen |
| 19:02 |
|
geoffsams joined #evergreen |
| 19:36 |
|
eby joined #evergreen |
| 21:29 |
|
sarabee joined #evergreen |
| 22:01 |
|
sbrylander joined #evergreen |
