| # | Time | Nick | Message |
|---|
| # | 00:12:22 | bshum has quit IRC |
| # | 00:29:48 | bshum has joined #evergreen |
| # | 02:57:52 | bshum has quit IRC |
| # | 03:12:58 | bshum has joined #evergreen |
| # | 06:47:33 | artunit_ has joined #evergreen |
| # | 06:47:35 | artunit has quit IRC |
| # | 06:47:36 | artunit_ is now known as artunit |
| # | 07:41:43 | plux has joined #evergreen |
| # | 08:42:25 | tspindler has joined #evergreen |
| # | 08:44:17 | kmlussier has joined #evergreen |
| # | 08:50:31 | AaronZ-PLS has joined #evergreen |
| # | 08:58:35 | akilsdonk has joined #evergreen |
| # | 09:10:04 | Meliss has joined #evergreen |
| # | 09:18:50 | kivilaht1o has joined #evergreen |
| # | 09:22:15 | kivilaht1o | hi #evergreen. Is it normal that on a quad server, importing a 200000 large set of biblio entries takes over 24 hours? |
| # | 09:22:55 | dbs has joined #evergreen |
| # | 09:22:55 | dbs has joined #evergreen |
| # | 09:23:05 | kivilaht1o | I was running the psql-command on a remote connection, which failed after 8 hours. But ps aux shows the process still running and hogging 98% of CPU time |
| # | 09:23:37 | kivilaht1o | And the process uptime is ~1700 minutes |
| # | 09:23:42 | kivilaht1o | can it really be so freaking slow? |
| # | 09:24:21 | dbs | kivilaht1o: postgresql can't use multiple processes to satisfy a single transaction, so there's that |
| # | 09:24:43 | kivilaht1o | so it is running in single core mode |
| # | 09:24:56 | kivilaht1o | I mean utilizing only one core |
| # | 09:24:57 | kivilaht1o | damn |
| # | 09:26:13 | kivilaht1o | So it might take like several days to import that biblio set, and it is only 40% of the bibliographic data we have, and in addition we need to import copy data for those biblios |
| # | 09:26:45 | dbs | kivilaht1o: there are ways to decrease loading times that have been discussed and used on the list |
| # | 09:26:46 | kivilaht1o | and ofc at some point the import fails and psql ROLLBACKs ;) |
| # | 09:26:56 | kivilaht1o | ok |
| # | 09:28:11 | dbs | but yes, the out-of-the-box "throw 200K records in a single import" approach can be insanely slow |
| # | 09:28:58 | kivilaht1o | i dropped a test import of 100 000 records and it went nicely in one night |
| # | 09:29:10 | dbs tries to remember some of the pertinent bits off the top of his head: tuning postgresql first and foremost; disabling some triggers; ... |
| # | 09:30:02 | kivilaht1o | dbs: I had to play around with disabling rules and triggers when deleting the test biblios |
| # | 09:30:37 | dbs | heh, yeah, the ON DELETE triggers would mess that up :) |
| # | 09:30:55 | kivilaht1o | also had some trouble with the reporter |
| # | 09:31:37 | kivilaht1o | But postgre can handle a large import file? The loading time wont increase exponentially to the size of the import file? |
| # | 09:32:04 | kivilaht1o | or should I really add it in small 10 000 biblio chunks? |
| # | 09:32:42 | kivilaht1o | I can do that, but it feels pretty lame, considering the maturity of psql. Well I'll google around |
| # | 09:33:14 | dbs | oh, and importing in parallel |
| # | 09:33:41 | kivilaht1o | parallel is good in multipprocessor , ok |
| # | 09:34:14 | dbs | right - see how things go with 4 batches of 50K simultaneously; that'll use up all four cores |
| # | 09:35:16 | kivilaht1o | but I dont really feel like stopping the process now after 30 hours of computing |
| # | 09:35:30 | kivilaht1o | unless the time increases exponentially compared to the size |
| # | 09:36:13 | dbs | I don't think it's truly exponential, but there's probably more contention for locking-ish resources as the size of an individual transaction increases |
| # | 09:37:28 | kivilaht1o | dbs: the server is totally nonresponsive, so it feels odd that psql would use only 1 core, and ps aux displays 100% as 100% of all cores combined? |
| # | 09:37:32 | dbs | and just to check - you have tuned postgresql right? |
| # | 09:37:38 | kivilaht1o | no tuning |
| # | 09:37:42 | dbs | yikes |
| # | 09:37:50 | kivilaht1o | dbs: wasn't in the migration guide |
| # | 09:38:07 | kivilaht1o | dbs: I have very limited proficiency with psql |
| # | 09:38:19 | dbs | We don't cover basic postgresql administration because the postgresql resources are way better than we could ever hope to provide |
| # | 09:38:28 | dbs | Step 1. Install pg_tune |
| # | 09:38:45 | dbs | Step 2. Run pg_tune and apply recommended changes for a "mixed" workload to your postgresql.conf |
| # | 09:38:54 | kivilaht1o | well maybe you could add a line to the install section hinting about tuning psql |
| # | 09:39:02 | kivilaht1o | but |
| # | 09:39:05 | kivilaht1o | ill do that |
| # | 09:39:12 | kivilaht1o | thanks a lot dbs |
| # | 09:39:22 | dbs | Step 3. Consult PostgreSQL documentation, tutorials, presentation, etc, for expert & trustworthy advice :) |
| # | 09:39:36 | kivilaht1o | three steps to postgres happiness |
| # | 09:39:44 | dbs | kivilaht1o: yeah, probably a good idea to at least flag that for people getting into serious evergreen usage |
| # | 09:40:42 | Dyrcona has joined #evergreen |
| # | 09:41:21 | dbs | also, I bet "ps" is really just showing 100% for a single process - if you can install pg_top, you can see what PostgreSQL processes are running and what the current stmt is for each one - nice for knowing where the bottleneck is occurring |
| # | 09:41:50 | dbs realizes that he probably should have submitted a "PostgreSQL administration tips & tricks" talk / round-table for the conference |
| # | 09:42:40 | kivilaht1o | dbs: so does dbs come from database specialist? |
| # | 09:47:23 | dbs | kivilaht1o: heh, no, simply my initials. but it did play nicely when I worked for the DB2 team years ago |
| # | 10:04:08 | tspindler has quit IRC |
| # | 10:10:28 | StephenGWills has joined #evergreen |
| # | 10:12:01 | Callender has quit IRC |
| # | 10:12:34 | tsbere reads scrollback and sees a comment about the backlog |
| # | 10:12:55 | tsbere doesn't want people wasting time feeling sorry for him in that regard. That time is better spent writing and/or reviewing patches ;) |
| # | 10:18:47 | dbs | tsbere++ |
| # | 10:19:19 | bshum | dbs: Maybe we can sneak PG admin tips in as a subject assuming that we get our sys admin interest group time slot again during Hackfest day. |
| # | 10:20:02 | bshum | Though, I'm sure you'd rather be hacking and coding ;) |
| # | 10:20:13 | mtate has quit IRC |
| # | 10:21:04 | dbs | bshum: I'm hoping gmcharlt is going to lead us to the hackfest-o'-testfest realm of glory |
| # | 10:24:15 | bshum | That sounds pretty cool actually. |
| # | 10:25:15 | dbs might be dreaming but thought that idea had been kicked around |
| # | 10:25:19 | bshum | So, is anyone running 2.0.10+ at the moment? I'm wondering if anyone's felt that logging into the staff client has become "slower" recently. |
| # | 10:26:07 | bshum | For us, it seems that it takes a couple extra beats longer to get to the "loading data..." and text scrolling across the screen. |
| # | 10:26:31 | bshum | And it's not just confined to a single server, but seems to have affected all our systems. |
| # | 10:26:57 | dbs assumes its the keyloggers |
| # | 10:27:08 | gmcharlt | dbs: *sssshhh!* |
| # | 10:27:23 | bshum | I'm going to poke at possible network issues, but I was the only one using the servers at 4 am last night and didn't think it should be so slow. |
| # | 10:27:36 | bshum | last night/this morning, |
| # | 10:27:42 | dbs | bshum: is login via srfsh similarly slow? |
| # | 10:27:44 | kivilaht1o | dbs: ok pg_top shows query plan: ERROR: syntax error at or near "COPY" |
| # | 10:28:01 | kivilaht1o | still processor is running at 90% |
| # | 10:28:25 | kivilaht1o | for the same process |
| # | 10:28:34 | bshum | dbs: Hmm, no an srfsh login came back pretty fast with success. Time to complete was 0.081090 |
| # | 10:28:35 | dbs | kivilaht1o: ugh. maybe all the work required to roll everything back now that it hit an error? |
| # | 10:28:38 | tsbere | bshum: Could be more https in the mix slowing things down. |
| # | 10:29:23 | kivilaht1o | dbs: no way of finding more info about the process history? |
| # | 10:29:45 | dbs | kivilaht1o: depends on what sort of logging you've configured for postgresql |
| # | 10:29:54 | kivilaht1o | vanilla |
| # | 10:30:11 | dbs | the error might be logged, then, depending on what the distro defaults to |
| # | 10:32:46 | kivilaht1o | it seems the error hapened with the EXPLAIN ANALYZE statement, not the initial COPY FROM statement |
| # | 10:33:37 | dbs | kivilaht1o: your EXPLAIN ANALYZE? |
| # | 10:33:52 | dbs | I assume that's not part of the normal import |
| # | 10:33:58 | kivilaht1o | pg_top uses EXPLAIN ANALYZE to read process info, right? |
| # | 10:34:32 | kivilaht1o | 2011-12-02 17:26:34 EET ERROR: syntax error at or near "COPY" at character 17 |
| # | 10:34:35 | kivilaht1o | 2011-12-02 17:26:34 EET STATEMENT: EXPLAIN ANALYZE COPY biblio.record_entry (active,create_date,creator,deleted,edit_date,editor,fingerprint,id,last_xact_id,marc,quality,source,tcn_source,tcn_value,owner,share_depth) FROM '/home/oakadmin/evergreen_staging/pg_loader-output.bre.sql'; |
| # | 10:35:10 | bshum | tsbere: Hmm, that doesn't sound like it's a good thing. Any tips or suggestions about that? |
| # | 10:35:33 | tsbere | bshum: Trade-off. Security or speed. |
| # | 10:35:42 | dbs | security++ |
| # | 10:35:56 | moodaepo | bshum: We are running 2.0.10 and don't see the logging in to be slower. |
| # | 10:35:59 | kivilaht1o | dbs: at the time i started |
| # | 10:36:06 | kivilaht1o | dbs: mispost sorry |
| # | 10:36:55 | dbs | kivilaht1o: "EXPLAIN" I could see; "EXPLAIN ANALYZE" actually runs the statement though |
| # | 10:37:14 | bshum | tsbere: dbs: Indeed, security does sound better :) |
| # | 10:39:24 | dbs | (I suspect "EXPLAIN" doesn't work with COPY anyway because there's not really a possible execution plan for COPY) |
| # | 10:39:54 | kivilaht1o | so afaik the process could be just frozen |
| # | 10:41:04 | bshum | moodaepo: Hmm, I'll ponder that and see if maybe one of the patches we've applied since is different. It might still be a local network/system problem of some kind. |
| # | 10:41:26 | tsbere | bshum: There are several ways to tell if it is https related |
| # | 10:41:28 | bshum | moodaepo: We've applied many of the recent 2.0 patches straight out of the repo, so we're well past 2.0.10 |
| # | 10:42:21 | moodaepo | Ay you said 2.0.10 sir not 2.0.10+ : ) |
| # | 10:43:54 | bshum | moodaepo: Actually I'm pretty sure I said 2.0.10+ ;) |
| # | 10:44:15 | moodaepo | moodaepo-- |
| # | 10:44:22 | bshum | tsbere: Welcome to give those a try when you get a moment. |
| # | 10:44:28 | dbs | heh, "2.0.almost-11" ? |
| # | 10:45:14 | bshum should start a "we'll see if that gets fixed with our 2.2 upgrade next year" responder to new issues. |
| # | 10:45:36 | dbs | heh |
| # | 10:48:09 | dbs | So... for the community meeting report today, should we include a line like: "The development team is attempting to maintain a high degree of quality by ensuring that all code is reviewed and signed off by at least one other contributor before being committed." |
| # | 10:49:20 | dbs | "However, the development team is now struggling with a large backlog of requests for review, sign-off, and commits because testing and reviewing code currently takes a lot of manual effort." |
| # | 10:49:21 | tsbere | bshum: I would start by running "cat /proc/sys/kernel/random/entropy_avail" - If you have less than, say, 100 you may have a lack of entropy issue. That will have a negative effect on response times of all SSL services. |
| # | 10:52:20 | dbs | "At this point, dbs devolves into asserting for the umpteenth time that an automated test suite with realistic sample data and broad functional coverage, along with the requirement that branches include test cases to cover the conditions they are addressing, would help prevent future backlogs." |
| # | 10:52:28 | bshum | tsbere: I'm watching that on one of our bricks and it's going between 130 to 180 or so |
| # | 10:52:49 | tsbere | that isn't bad |
| # | 10:53:18 | bshum | Assuming that I should be checking that with the head of the brick that's running apache |
| # | 10:53:22 | tsbere thought there was a "stop doing SSL all the time" setting, but can't remember what it was and doesn't see references in obvious places |
| # | 10:53:25 | bshum | And not all 3 servers. |
| # | 10:53:54 | dbs | "However, the development team currently lacks a good set of sample templates for regression tests and that is a significant inhibitor for making any progress on that front." |
| # | 10:53:55 | tsbere | dbs: realistic sample data would need to include 100% invalid data that the current schemas won't accept, right? |
| # | 10:54:00 | dbs | "So, whaddya going to do?" |
| # | 10:54:20 | dbs | tsbere: you mean my data? |
| # | 10:54:22 | bshum | tsbere: presumably? http://ur1.ca/6an3f |
| # | 10:54:29 | bshum | tsbere: We didn't apply that one. |
| # | 10:55:13 | tsbere | bshum: Oh, no, not that one. That one would slow things down horribly though. |
| # | 10:56:37 | dbs wonders how handful-of-requests TPAC under all SSL would compare to handfuls-and-feetfuls-of-requests JSPAC without SSL |
| # | 10:58:05 | tsbere | bshum: You apply cc90dc82cec13df46ba828b1e2727add17d28505 locally? |
| # | 10:58:27 | dbs | Oh, I guess the community would be interested in "next 2.2 cut", which I would suspect would be another alpha (don't want to freeze the schema yet). Maybe next week? |
| # | 10:58:32 | tsbere | dbs: The problem isn't *finding* the data. Most of us have it. The problem is getting it into the schema once we made the schema start rejecting it. |
| # | 11:01:13 | dbs | tsbere: sure, like the missing 901s and such, or our invalid MARC. that doesn't seem like a reason to not bother trying to have any functional tests or sample data though |
| # | 11:01:57 | dbs | (and triggers can be disabled at sample data import time for those specific known rows of bad data) |
| # | 11:03:25 | dbs | the alternative seems to be a massive amount of manual effort and/or more regressions and/or slower release cycles |
| # | 11:06:29 | Dyrcona | or no release cycles and we tell people to run master. |
| # | 11:06:48 | bshum | tsbere: Alright, I'll bite, can you remind me how to search for the hash string of git commits like that again? :S |
| # | 11:07:32 | tsbere | git branch with the contains option, git log with / searching, or just doing git show to see the commit? |
| # | 11:07:53 | dbs | Dyrcona: whether you wrap it in a tarball or pull directly from git, the amount of effort to review & test doesn't change |
| # | 11:08:33 | kmlussier | dbs: I know several people who are not only interested in the next 2.2 cut but how/when 2.2 is determined to be ready for beta. |
| # | 11:08:34 | dbs | (and the release artifact encourages us to do things we should be doing anyway, like write release notes) |
| # | 11:08:49 | bshum | tsbere: Thanks, git show worked fine for me. |
| # | 11:08:53 | dbs | kmlussier: answer: we have no formal answer |
| # | 11:08:59 | bshum | tsbere: No, we did not apply that to our servers at all. |
| # | 11:09:20 | bshum | At least I don't think I did... will double check. |
| # | 11:10:02 | dbs | Releases are getting closer to being time-based things rather than feature-based things, in which case we would start to be able to predicting releases with much more accuracy |
| # | 11:10:56 | dbs | (ah, and another benefit of tarballs: you can say: "Requires a minimum of component version X; does not support component version Y in this release" whereas that can change rather severely in master) |
| # | 11:11:10 | kmlussier | I think it's as much of a process question as a "when does it happen" question. And I would be interested in knowing what non-developers can do to help move the release forward, like testing, bug reporting, helping with release notes, etc. |
| # | 11:12:12 | dbs | kmlussier: so with a time-based release and stable master (which we're striving for), "beta" is "one month before final release" (adjust "one month" by whatever we would want to do) |
| # | 11:12:50 | dbs | testing and bug reporting is part of development in my mind, so testers and developers are part of the development team whether they like it or not :) |
| # | 11:13:43 | mrpeters-isl has joined #evergreen |
| # | 11:17:36 | dbs | "The structure of the development team includes the Evergreen bug wranglers (people who report bugs and test suggested code - open to anyone), "Evergreen drivers" (bug wranglers who have the ability to target bugs to specific releases); the "Evergreen release team" (committers plus chief bug wrangler); and the Evergreen security team (release team + members of the community with a demonstrated understanding of how to address security vulnerab |
| # | 11:17:36 | dbs | ilities)." |
| # | 11:17:39 | dbs | ? |
| # | 11:18:01 | bshum | +1 |
| # | 11:20:42 | Dyrcona | kmlussier: I would say to the people wanting to know how/when 2.2 is ready for beta is that their help in testing 2.2 is most appreciated. (Of course, I also know who you are talking about, specifically.) |
| # | 11:20:52 | bshum | tsbere: Found it |
| # | 11:21:05 | bshum | tsbere: http://ur1.ca/6anqy |
| # | 11:21:09 | bshum | That's what's slowing us down |
| # | 11:21:16 | bshum | But it sounds pretty important to retain. |
| # | 11:21:39 | tsbere | Heh. "Require more CPU-intensive cipher suites" would slow things down a tad. |
| # | 11:21:57 | mrpeters-isl has quit IRC |
| # | 11:22:41 | dbs | bshum: only important if you want to prevent people from DoS'ing your server |
| # | 11:22:42 | Dyrcona | bshum: so related to SSL after all, but not running out of entropy? |
| # | 11:22:43 | kmlussier | dbs and Dyrcona: Thanks! I'll be doing my share of testing shortly. |
| # | 11:23:56 | Dyrcona | I'd also suggest that if people really want to test upcoming releases, that they actually install from git rather than from tarballs. |
| # | 11:24:14 | dbs | http://git.evergreen-ils.org/gitstats/Evergreen/activity.html (thanks tsbere!) illustrates commit pace - if eeevil hadn't gone on that "sacrifice testing to address the backlog" commit tear a few weeks back, it would be even more graphic ("0" = this week, "1" = 1 week ago) |
| # | 11:24:46 | ElliotFriend has joined #evergreen |
| # | 11:25:23 | bshum | dbs: Sounds pretty important :P |
| # | 11:25:33 | tsbere | dbs: Apparently things just stay slow during october-january as well? |
| # | 11:26:01 | dbs | Dyrcona: that's a bit problematic because it requires people to use git, to know what commits are in the repo at the time they're testing, to get the version upgrade scripts into master (hey, there's a branch for that) - raises the bar for testing |
| # | 11:26:51 | dbs | tsbere: the scale of that graph (for "by month") is a bit misleading |
| # | 11:27:54 | dbs | in 2009, October/November were the 2nd and 4th most prolific months |
| # | 11:28:45 | bshum | Hmm, I forgot that ESI was moving today. Wonder if that means we'll have a lighter attendance from them this afternoon... |
| # | 11:28:47 | dbs | In 2008, October/November/December were the most prolific months |
| # | 11:28:47 | kmlussier | At this point in the release cycle, if I am testing against master (since Dyrcona is so kind to give me access to master), am I essentially testing 2.2. alpha or are there distinctions that might muddle my testing? |
| # | 11:28:48 | Dyrcona | dbs: If you install from the start with git, you don't need version upgrade scripts. |
| # | 11:29:01 | adbowling-isl has joined #evergreen |
| # | 11:29:21 | Dyrcona | kmlussier: you are testing 2.2 alpha plus a few things that haven't made it in yet when you use my server. |
| # | 11:29:38 | adbowling-isl | if any of the ESI support guys are in channel here, please PM me. |
| # | 11:30:51 | Dyrcona | master == 2.2alpha1 + what will be in 2.2alpha2 |
| # | 11:32:33 | Dyrcona | master == 2.2 pre release until rel_2_2 is tagged, correct? |
| # | 11:32:53 | tsbere | basically |
| # | 11:32:56 | Dyrcona | or branched, whatever the appropriate term is in git. :) |
| # | 11:32:59 | dbs | Dyrcona: _I_ can (and have) run production Evergreen straight from the repo. You can, and some other people can. But it's time consuming, requires even more skill than we're already demanding of people (who often are new to Linux), and pretty damned hard to associate with artifacts like documentation |
| # | 11:33:29 | kmlussier has quit IRC |
| # | 11:36:04 | Dyrcona | All right, if a bug was fixed in master prior to 2.2 alpha 1, should I mark it fix released? |
| # | 11:36:11 | dbs | Anyway, in my opinion "to run out of git or to provide releases" isn't an either-or proposition and does nothing to address quality concerns or related backlog issues. |
| # | 11:36:47 | dbs | We could include a "as a testimonial to master's quality, some developers advocate running Evergreen straight from master" in the report though - there is that |
| # | 11:37:10 | graced has joined #evergreen |
| # | 11:37:14 | Dyrcona | We run it straight from master in production. |
| # | 11:37:20 | dbs | Dyrcona: I would, assuming that the target was master |
| # | 11:37:29 | Dyrcona | Ok, dbs, will do. |
| # | 11:37:35 | dbs | Dyrcona: I know. You've mentioned that many times. |
| # | 11:37:41 | Dyrcona | I've decided to do some bug wrangling on my "day off." ;) |
| # | 11:37:56 | Dyrcona is a bit mouthy. :) |
| # | 11:38:00 | dbs | heh |
| # | 11:38:10 | dbs | I think I have you beat in that department |
| # | 11:38:22 | kmlussier has joined #evergreen |
| # | 11:38:25 | dbs fears what an ircstats run would show |
| # | 11:40:18 | Dyrcona | Would it be worthwhile targeting bugs at 2.0 at this point? I think so, but others opinions are welcome. |
| # | 11:41:22 | dbs | absolutely |
| # | 11:41:36 | dbs | 2.0 is still supported |
| # | 11:46:40 | timhome_ has quit IRC |
| # | 11:47:04 | timhome_ has joined #evergreen |
| # | 11:50:02 | dbs | http://evergreen-ils.org/dokuwiki/doku.php?id=dev:reports:2011-12-02 as a basis for today's community meeting report? |
| # | 11:50:37 | dbs | oh, need a word about 2.2 release expectations - +1/-1 to cutting alpha2 next week? |
| # | 11:51:20 | Dyrcona wonders when 2.0.11 will be released.....I'm leaving some bugs open because 2.0.11 hasn't gone up, yet. |
| # | 11:52:36 | dbs | yeah, there's a bunch of bug fixes that have built up for 2.0.11 |
| # | 11:53:09 | dbs | I'd take a stab at it but my time is limited with the TPAC fest next week :/ |
| # | 11:56:36 | Dyrcona | +1 for alpha2 |
| # | 11:59:23 | dbs | Dyrcona: wait a minute - why did you change assign me to 825039? I thought "assigned to" was for people who were going to take the next step, and as far as I can tell the next step is "someone tests/reviews and signs-off" (which I can't do because I'm the author) |
| # | 11:59:42 | Dyrcona | I did that cause you were working on it. |
| # | 11:59:51 | Dyrcona | I'll undo it, then. |
| # | 12:00:35 | dbs | Unless you're thinking that I should backport it to rel_2_1 / rel_2_0? I'm a bit reluctant to force a reingest, but could be convinced that it's worthwhile... |
| # | 12:01:13 | dbs | As far as master goes, though, I'm done |
| # | 12:14:36 | Dyrcona won't do any more assignments. :) |
| # | 12:14:47 | akilsdonk has quit IRC |
| # | 12:15:06 | Dyrcona | bshum or anyone else, can you confirm this in 2.0/2.1? https://bugs.launchpad.net/evergreen/+bug/890754 |
| # | 12:15:45 | bshum | Hmm |
| # | 12:15:55 | bshum | Can't remember what prompted me to write that in that day |
| # | 12:18:00 | bshum | Looking at the logs I guess I was looking for hold related bugs due to quirks with that automated expiration of holds placed in the past. |
| # | 12:18:17 | bshum | I'll see if I can confirm, but we aren't using that library setting currently. |
| # | 12:18:44 | graced has quit IRC |
| # | 12:20:25 | graced has joined #evergreen |
| # | 12:21:45 | bshum | Hmm |
| # | 12:21:47 | bshum | That's new isn't it |
| # | 12:21:55 | bshum | That we can un-target a bug from a series |
| # | 12:26:57 | dbs | I've updated http://evergreen-ils.org/dokuwiki/doku.php?id=dev:reports:2011-12-02 somewhat to include the items that were on the community agenda |
| # | 12:28:16 | dbs | (and omitted the TPAC @ Windsor announcement because hey, development happens everywhere!) |
| # | 12:28:33 | dbs | bshum: sounds brand spanking new. and helpful |
| # | 12:29:12 | dbs | so you can untarget, and then decline the nomination? |
| # | 12:30:07 | bshum | I think so. |
| # | 12:30:30 | dbs | cool |
| # | 12:31:09 | bshum | The 2.0 release process is still like what eeevil wrote on his scratchnotes for how to build a release right? |
| # | 12:31:35 | bshum did it once for a self-made 2.0.6 tarball, could probably try again with 2.0.11... |
| # | 12:32:41 | dbs | bshum: yep, largely, although the release should be tagged in git |
| # | 12:32:52 | bshum | dbs: Ah right, that I couldn't do ;) |
| # | 12:32:55 | AaronZ-PLS has quit IRC |
| # | 12:33:44 | Dyrcona | Lots of bug fixes for 2.0.11, that's for sure. |
| # | 12:34:20 | Dyrcona | If someone could tag it for you, do you think you could release it, bshum? |
| # | 12:36:17 | bshum | I'd be willing to give it a try next Tuesday; usually have time before/after dev meeting. I think eeevil wrote enough on the wiki for me to piece one together. |
| # | 12:36:34 | Dyrcona | bshum++ |
| # | 12:36:58 | dbs could merge whatever needs to be merged from bshum's branch into rel_2_0 and tag the release if it's all good |
| # | 12:37:11 | Dyrcona | I can't tag it, but I'm sure dbs or tsbere could. I'd like to close the 2.0.11 bugs. |
| # | 12:37:31 | Dyrcona | dbs: sounds like a plan. |
| # | 12:38:15 | bshum | I think the hardest thing is making sure the upgrade script is good. |
| # | 12:38:52 | matt_carlson has joined #evergreen |
| # | 12:43:01 | matt_carlson has quit IRC |
| # | 12:47:56 | edoceo | Can someone pastebin a copy of their OpenILS/Utils/Cronscript.pm ? Specifically I'm looking for what value is set for "osrf-config" in default_opts, (around line 57) |
| # | 13:00:26 | graced_ has joined #evergreen |
| # | 13:00:53 | graced has quit IRC |
| # | 13:00:56 | graced_ is now known as graced |
| # | 13:01:44 | AaronZ-PLS has joined #evergreen |
| # | 13:02:01 | dbs will grab said copy |
| # | 13:02:28 | matt_carlson has joined #evergreen |
| # | 13:02:54 | edoceo | Appears what is happening, on ./configure is that @sysconfdir@ is begin replaced with the string '${prefix}/' - but it should be putting in my defined prefix "/opt/openils" |
| # | 13:02:57 | dbs | edoceo: /openils/conf/opensrf_core.xml on our 2.0.10-ish server |
| # | 13:03:25 | edoceo | Mine shows: 'osrf-config=s' => '${prefix}/etc/opensrf_core.xml' |
| # | 13:03:40 | dbs | edoceo: running from a tarball or from a git branch? |
| # | 13:03:44 | dbs | what version? |
| # | 13:03:45 | edoceo | master |
| # | 13:03:45 | dbs | etc |
| # | 13:04:03 | edoceo | git pull yesterday, but saw this when I was using release of 2.1x |
| # | 13:04:14 | dbs | when's the last time you cleaned things out and reran ./autogen.sh? |
| # | 13:04:20 | edoceo | twice today |
| # | 13:04:37 | edoceo | wiped entire src dir, redid full clone |
| # | 13:05:20 | dbs just ran the ./configure && make dance and has "/openils/conf/..." |
| # | 13:05:29 | dbs | (master, plus a ton of other branches) |
| # | 13:05:46 | edoceo | hrm |
| # | 13:06:13 | dbs | distro? version of autoconf / automake? |
| # | 13:06:49 | edoceo | gentoo, autoconf 2.65, automake 1.11 |
| # | 13:07:06 | dbs | ah, gentoo |
| # | 13:07:32 | dbs has autoconf 2.68 on fedora 16 |
| # | 13:08:08 | dbs | edoceo: are you specifying --sysconf? |
| # | 13:09:02 | dbs can reproduce the problem edoceo describes if he doesn't |
| # | 13:09:47 | dbs | so there's a bug there - it should get --prefix's value if not specified |
| # | 13:12:28 | edoceo | nope, just --prefix (generally works) |
| # | 13:13:07 | dbs | yep, but all of our docs specify --sysconf so it never gets tested without |
| # | 13:13:14 | dbs | http://lists.gnu.org/archive/html/help-gnu-utils/2005-09/msg00027.html - no reply |
| # | 13:15:28 | dbs | so many questions left unanswered: http://lists.debian.org/debian-user/2000/07/msg01936.html |
| # | 13:15:32 | dbs | How about that CMake? |
| # | 13:15:36 | edoceo | fixed, |
| # | 13:17:34 | edoceo | I'll just note to self about --sysconfdir, but I though --syconfdir was built from prefix, if not defined, |
| # | 13:18:49 | dbs | edoceo: that's what we would like to happen, for sure - like I said "so there's a bug there..." |
| # | 13:19:07 | dbs | if you've got an idea about fixing it, please go ahead |
| # | 13:19:14 | dbs | pretty please! |
| # | 13:20:09 | edoceo | well, since you asked nicely |
| # | 13:21:28 | mrpeters-isl_ has joined #evergreen |
| # | 13:32:57 | brian_f has joined #evergreen |
| # | 13:35:28 | wolf29 has quit IRC |
| # | 13:45:36 | jenny has joined #evergreen |
| # | 13:46:58 | bshum | Oh, vote... |
| # | 13:46:59 | bshum | Right :S |
| # | 13:47:36 | akilsdonk has joined #evergreen |
| # | 13:47:38 | dbs | heh |
| # | 13:47:52 | bshum | See I read the rest of the email and thought it sounded good. |
| # | 13:48:05 | bshum | Just didn't see the "please vote" part |
| # | 13:48:07 | dbs noted that he had not voted, but worries a bit that the request for vote had been cross-posted |
| # | 13:48:18 | dbs | so votes could come in on two different lists :) |
| # | 13:48:27 | bshum | Yeesh |
| # | 13:48:52 | dbs goes to grab some food |
| # | 13:51:49 | tsbere wonders if he should go look at his email, not knowing what is being voted on |
| # | 13:53:49 | csharp | tsbere: EOL policy |
| # | 13:54:06 | bshum | dbs: afterl told me she wasn't going to be able to make the meeting today, and had mentioned something about notes for governance being added to the agenda; but I don't see her edits anywhere. |
| # | 13:55:42 | rwalsh has joined #evergreen |
| # | 13:58:45 | tspindler has joined #evergreen |
| # | 13:59:48 | kmlussier | bshum: she posted a link to http://paste.lisp.org/display/126231 to the agenda. |
| # | 13:59:51 | mrpeters-isl_ | someone from indiana will be in shortly as well...i'm unavailable at the moment dealing with server issues |
| # | 14:00:39 | bshum | kmlussier: Oh there it is, must not have refreshed properly... :S |
| # | 14:00:46 | bshum | Well, time is upon us. |
| # | 14:01:06 | bshum | We can start with introductions to see who's here, while we look for meeting leader/minute taker volunteers too. |
| # | 14:01:32 | kmlussier is Kathy Lussier, MassLNC |
| # | 14:01:41 | bshum changes topic to "Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://pastebin.ca or http://paste.lisp.org/new/evergreen or something like that | Community Meeting Agenda: http://ur1.ca/6armv" |
| # | 14:01:52 | phasefx_ is Jason Etheridge, Equinox |
| # | 14:01:55 | bshum is Ben Shum, Bibliomation |
| # | 14:01:56 | csharp is Chris Sharp, Georgia Public Library Service |
| # | 14:02:00 | tspindler | * tspindler is Tim Spindler, C/W MARS |
| # | 14:02:21 | rwalsh | *rwalsh is Rob Walsh, Excalibur Solutions (formerly with EnvisionWare)* |
| # | 14:02:28 | brian_f Brian Feifarek, Northfork Software |
| # | 14:02:44 | jamesrf is James Fournie, BC Libraries Cooperative / Sitka |
| # | 14:02:48 | graced is Grace Dunbar, Equinox |
| # | 14:03:02 | dbs is Dan Scott, Conifer / Laurentian University |
| # | 14:03:28 | bshum | I'll volunteer to walk us through our agenda today. |
| # | 14:03:41 | akilsdonk is Angela Kilsdonk, Equinox |
| # | 14:03:42 | bshum | Unless someone else wants it. |
| # | 14:03:57 | dbs | bshum++ |
| # | 14:04:24 | mrpeters-isl_ Michael Peters, Evergreen Indiana |
| # | 14:04:24 | tsbere is Thomas Berezansky, Merrimack Valley Library Consortium |
| # | 14:05:13 | moodaepo <-- Anoop Atre PALS |
| # | 14:05:45 | rangi | Chris Cormack, Catalyst (mostly lurking) |
| # | 14:06:05 | bshum | Alright, well, as others show up, please feel free to introduce yourselves, but let's get this meeting rolling. |
| # | 14:06:26 | moodaepo volunteers to do minutes if nobody else has yet |
| # | 14:06:38 | bshum | moodaepo++, was just about to ask for the volunteer ;) |
| # | 14:06:48 | bshum | So, here we go. |
| # | 14:06:54 | bshum | 3. Review action items from last meeting |
| # | 14:07:07 | moodaepo | topic |
| # | 14:07:13 | bshum | I. moodaepo (Anoop Atre) will set up proxy (postfix aliases) for primary contacts of each group on the Evergreen committees page. |
| # | 14:07:18 | moodaepo | Done |
| # | 14:07:37 | bshum | Cool |
| # | 14:07:45 | bshum | II. gmcharlt (Galen Charlton) will update the domain to point to this year's conference web site. (also reported done) |
| # | 14:08:10 | bshum | I note that conference.evergreen-ils.org points at the main Evergreen page. |
| # | 14:08:12 | dbs | http://conference.evergreen-ils.org/ leads to the regular evergreen-ils.org for me |
| # | 14:08:16 | bshum | But at least it resolves? |
| # | 14:08:20 | dbs | heh :) |
| # | 14:08:53 | bshum | Maybe we make it an action item to follow up with gmcharlt/ESI on that. |
| # | 14:09:19 | dbs | +1 |
| # | 14:09:52 | graced | I can ping gmcharlt about it and make sure it gets done |
| # | 14:10:04 | moodaepo | graced++ |
| # | 14:10:30 | bshum | Thanks graced |
| # | 14:10:35 | bshum | Next, 4. Communications Committee & Website Team. Anybody from that group here to report? |
| # | 14:11:04 | mrpeters-isl_ | type "/me Adam Bowling, Evergreen Indiana" |
| # | 14:11:26 | mrpeters-isl_ | oops...PM fail...sorry |
| # | 14:11:37 | bshum | *crickets* |
| # | 14:11:48 | phasefx_ | website is up :) |
| # | 14:11:58 | bshum | Okay, well, phasefx had put an agenda item on the there for ideas to handle SSL cert errors for the public demo servers. |
| # | 14:12:17 | tsbere is "attending" for that one item |
| # | 14:12:20 | bshum | Perhaps we should make that into a discussion thread if folks aren't here to talk about it today? |
| # | 14:12:40 | bshum | Alternatively, I'll let phasefx take that one for discussion right now. |
| # | 14:12:43 | phasefx_ | there was some feedback pointing it out to us, presumably because it's bad having SSL errors in the client :) |
| # | 14:13:11 | adbowling-isl is Adam Bowling, Evergreen Indiana (in case you hadn't guessed that I was coming) |
| # | 14:13:13 | phasefx_ | we could just add instructions for how to deal with it, note that it's expected, etc. |
| # | 14:13:20 | moodaepo | phasefx_: +1 |
| # | 14:13:25 | dbs | +1 |
| # | 14:13:26 | phasefx_ | or we could pony up for a cert, etc. |
| # | 14:13:53 | mrpeters-isl_ | instructions should suffice |
| # | 14:14:00 | phasefx_ likes the instructions route, but can see that it might scare some folks trying EG out |
| # | 14:14:14 | bshum | I think instructions are good. If the volunteers who operate the demo servers want to have certs, I think that's their choice. |
| # | 14:14:20 | dbs | a wildcard cert for *.demo.evergreen-ils.org ? |
| # | 14:14:32 | Dyrcona | yeah. I'm not people will always read instructions. |
| # | 14:14:37 | tsbere | If a cert is grabbed, I would vote for a wildcard one. |
| # | 14:14:42 | Dyrcona | +1 to wildcard cert |
| # | 14:15:00 | tsbere | And then give it to anyone who is hosting a demo server. We don't need "real" security for the demo servers. |
| # | 14:15:06 | Dyrcona is apparently still napping. |
| # | 14:15:09 | phasefx_ | and while instructions for staff client are simple enough, instructions for the OPAC with arbitrary browsers.. not so much |
| # | 14:15:21 | phasefx_ | see, I used the word arbitrary correctly :) |
| # | 14:15:56 | adbowling-isl | i'm late to the conversation, so I apologize in advanced, but would a self-signed cert not work for demo? |
| # | 14:16:00 | bshum | Public demo servers are mainly under brian_f's control right now right? |
| # | 14:16:11 | csharp | +1 for a wildcard cert - agreed that the hurdle for SSL exceptions is too high for new users |
| # | 14:16:38 | bshum | (though I now see the 1.6.1.2 listed server by ESI) |
| # | 14:16:59 | phasefx_ | Lyrasis has one too |
| # | 14:17:02 | bshum | http://evergreen-ils.org/dokuwiki/doku.php?id=community_servers |
| # | 14:17:02 | moodaepo | bshum: And that can go away since we don't support 1.6 |
| # | 14:17:02 | dbs | So, that would require all demo servers to be accessible under a consistent set of hostnames? |
| # | 14:17:06 | bshum | For those following along |
| # | 14:17:21 | moodaepo | dbs: +1 if that's possible |
| # | 14:17:24 | dbs | master.demo.evergreen-ils.org, rel_2_2.demo.evergreen-ils.org, etc? |
| # | 14:17:40 | tsbere | Yea, a wildcard cert would require that they be one level under the main domain. So no a.b.demo.evergreen-ils.org |
| # | 14:17:59 | dbs | right |
| # | 14:18:13 | dbs | Sounds like grist for another mailing list discussion! |
| # | 14:18:36 | phasefx_ | final point in favor of a cert, makes us look more professional |
| # | 14:19:01 | phasefx_ | if we want to make good first impressions as we grow the community |
| # | 14:19:10 | mrpeters-isl_ | so, someone will maintain the domains, for example, the Indiana master server. Someone will point DNS to our server for say, "master1.evergreen-ils.org" and so on? |
| # | 14:19:17 | dbs | FWIW, if we get some holiday donations to the project (hint hint!), the Oversight Board would probably approve the expenditure for a cert. Can't guarantee it, but I would bring it forward |
| # | 14:20:00 | ElliotFriend | Can we provision one demo server with the most up-to-date software on it as the "potential user" server. Pop for just one cert? |
| # | 14:20:46 | Dyrcona | ElliotFriend: It is more efficient, setup-wise, to get a wildcard cert for multiple servers under 1 domain. |
| # | 14:20:54 | phasefx_ doesn't know, but would imagine a wildcard cert isn't insanely more expensive |
| # | 14:21:25 | dbs thinks a few hundred dollars per year - been a while since we purchased ours |
| # | 14:21:32 | mrpeters-isl_ | 199/yr at GoDaddy |
| # | 14:21:33 | moodaepo | phasefx_: Would you start of the discussion on the mailing list por favor? |
| # | 14:21:41 | dbs | moodaepo++ |
| # | 14:21:43 | mrpeters-isl_ | and they alwyas seem to be cheapest |
| # | 14:22:10 | moodaepo knows a cheaper source and 'might' volunteer once discussion is complete |
| # | 14:22:11 | adbowling-isl | $199 @ RapidSSL, as well |
| # | 14:22:19 | phasefx_ | I do like the cosmopolitan feel of having many demo servers with different hostnames.. I wouldn't want to mandate that all demo servers us some common cert and hostname scheme if the folks behind them didn't want to |
| # | 14:22:24 | mrpeters-isl_ | discounts of about 10% if you go multiple years |
| # | 14:22:31 | bshum | moodaepo: Was going to suggest your suggestion (since we got ours via your suggestion) |
| # | 14:22:38 | phasefx_ | moodaepo: I'll do so |
| # | 14:22:44 | moodaepo | phasefx_++ |
| # | 14:23:07 | mrpeters-isl_ | is there anyone that has the capability of hosting a demo server for each of the 2 most recent releases, plus master on one server? |
| # | 14:23:48 | mrpeters-isl_ | just dump the database each night, and for master i'm sure we could automate nightly builds and service restarts right? |
| # | 14:23:49 | dbs | phasefx: right - if FooBar(tm) wants to advertise their 2.2 demo server as demo.foobar.com and pony up for an SSL cert, cool in my books |
| # | 14:24:16 | dbs | +1 to further discussion on lists |
| # | 14:24:17 | moodaepo | mrpeters-isl_: I can't promise without sign-off but we could provide servers for whoever is managing the demo servers |
| # | 14:24:32 | brian_f | sorry I got an urgent call just as the certs topic came up |
| # | 14:24:37 | moodaepo | +1 to moving this to list |
| # | 14:24:39 | mrpeters-isl_ | we probably could too, again pending signoff |
| # | 14:24:46 | brian_f | +1 to list |
| # | 14:24:58 | bshum | Okay, to be continued... |
| # | 14:25:02 | kmlussier | I can do a quick report for the web team. Sorry, I was distracted by something else when we reached that point in the agenda. |
| # | 14:25:06 | mrpeters-isl_ | we could have 1 set of "official" demo servers listed, on the open-ils.org domain |
| # | 14:25:15 | bshum | kmlussier: Sure thing, go ahead :) |
| # | 14:25:41 | mrpeters-isl_ | and then a "unofficial" section with the disclaimer they may not have ssl, etc. and provide instructions on how to except SSL |
| # | 14:25:47 | kmlussier | The web team has mostly been continuing discussion of an idea percolator where people can share their development ideas and maybe find co-sponsores. |
| # | 14:26:36 | kmlussier | We had explored a couple of solutions like Idea Torrent or a custom drupal web interface, but we also like the idea of not building another new place where people need to interact in the eg community. |
| # | 14:27:36 | kmlussier | We like the idea of maybe posting these early development ideas to Launchpad, since it's already being used by the Evergreen community. But since developers are already using it so heavily and being alerted whenever there is a new submission, we weren't sure if this might be too much stuff being posted to Launchpad. |
| # | 14:28:32 | kmlussier | We're mostly talking about ideas that have not yet been fleshed out with specifications. We just want a place where people can see what others might be working on earlier in the process. |
| # | 14:28:58 | kmlussier | Any thoughts on that? |
| # | 14:29:18 | dbs | kmlussier: if it's cheap and easy to throw up "ideas.evergreen-ils.org" or something like that for IdeaTorrent, I'd say try it out and see if it sticks |
| # | 14:29:19 | phasefx_ | a newsletter might help too, if anyone has an itch to revive that |
| # | 14:29:41 | phasefx_ | Classified: Looking for collaboration on Teen-PAC |
| # | 14:30:00 | bshum | If you're talking about using the LP's Blueprints, I don't think they overlap with regular bug mail traffic. At least not with what I've seen so far with the few blueprints I started tracking there. |
| # | 14:30:16 | phasefx_ | just to summarize things that get committed, things that show up on an idea torrent, etc |
| # | 14:30:16 | kmlussier | There are some technical issues with IdeaTorrent. It requires Drupal and is not being actively supported, which is why we were also looking at the custom Drupal app. |
| # | 14:30:56 | dbs worries about custom apps |
| # | 14:31:12 | moodaepo | kmlussier: Any non-Drupal options? |
| # | 14:31:19 | moodaepo kicks himself for having missed the meetings where this was discussed |
| # | 14:31:22 | kmlussier | We had looked at Blueprints, but it didn't seem to have some of the features we were looking for. We were looking at possibly submitting bugs as wishlist items, but maybe adding tags to them to distinguish them from the regular bug traffic. |
| # | 14:31:40 | dbs | Custom apps can quickly become a project of their own (which is good and bad) |
| # | 14:31:53 | csharp | idea torrent is in active use by Ubuntu: http://brainstorm.ubuntu.com/ - even if it's not being actively developed, that still means a big F/LOSS player is using it actively |
| # | 14:31:55 | bshum | kmlussier: Ah, then I see what you mean. |
| # | 14:32:07 | kmlussier | moodaepo: It's still being actively discussed. I just wanted to throw the idea out before we went too far down that road. :-) |
| # | 14:32:27 | bshum | kmlussier: Speaking as one of the bug wranglers, I'm not sure how much I like the idea, if only because we have such a backlog already to work through there. |
| # | 14:33:10 | csharp | as a non-developer/non-bug-wrangler subscribed to bug email, I would want to see it separate from Launchpad (fwiw) |
| # | 14:33:11 | kmlussier | One of the examples we had looked at was the Koha communtiy, which seems to be tracking their ideas with their bugs in Bugzilla. |
| # | 14:33:27 | dbs does find some of LaunchPad's assumptions jarring, and probably hard to throw ideas around in BluePrints |
| # | 14:33:44 | phasefx_ | just a warning, there's also a such thing as too many avenues of communication |
| # | 14:33:54 | dbs also suspects Dyrcona's work over the last few hours reinforces people's fears of getting deluged with bug mail :) |
| # | 14:33:58 | kmlussier | phasefx_: yes, that was one of our concerns |
| # | 14:34:16 | dbs | I guess the drawback of the mailing lists is that they're mailing lists? |
| # | 14:34:29 | Dyrcona chuckles. |
| # | 14:34:36 | adbowling-isl | phasefx_++ |
| # | 14:34:36 | tspindler | is the goal to have users +1 ideas so the best ideas move to the top? |
| # | 14:34:39 | mrpeters-isl_ is always fond of a nice vbulletin forum |
| # | 14:35:02 | jamesrf | BluePrints isn't much better than a wiki page |
| # | 14:35:27 | dbs | jamesrf: in some ways worse, due to the constraints |
| # | 14:35:38 | kmlussier | tspindler: that's one of the ideas. But also just to have a one-stop place to see what others are already working on. |
| # | 14:35:59 | csharp | if the ultimate goal is finding development partners, I think I'd be with dbs on using the tried-and-true lists |
| # | 14:36:17 | dbs would argue that git would be where you can see what people are actually working on (with respect to code) |
| # | 14:36:31 | tspindler | I personnaly would find it helpful separated from launchpad, i subscribe to the launchpad bugs but when I get a flurry (like today) i can't say i read through them |
| # | 14:36:32 | brian_f | But for fleshing out ideas/projects, a wiki might work better than sifting through mails |
| # | 14:36:43 | tsbere | mrpeters-isl_: I would vote for a different forum software, for the record. :P |
| # | 14:36:49 | dbs | there are web forum front ends for mailing lists that might make life easier |
| # | 14:37:07 | kmlussier | csharp: I would say that's just one of the goals. The ultimate goal really is to have a centralized place to see what ideas are percolating in the eg community and to maybe give support to ideas that you would like to see implemented. |
| # | 14:37:15 | mrpeters-isl_ | yeah, there are good OS options, tsbere |
| # | 14:37:35 | phasefx_ would love to go back to NNTP :) |
| # | 14:37:36 | dbs | so the mailing list people that like their email in plain text can have that, and people who want a visual web ui with search can have that, and everybody can play nice together ;) |
| # | 14:38:09 | mrpeters-isl_ | i like that idea |
| # | 14:38:19 | phasefx_ has tried gmane with our lists and NNTP, but is not sure about posting (just an aside) |
| # | 14:38:22 | mrpeters-isl_ | sometimes i just get so far behind on the mailing list i never catch up |
| # | 14:38:26 | kmlussier | OK, but what I'm hearing is that Launchpad probably isn't the best option, which means we should explore some of the other options we were looking at. |
| # | 14:38:42 | mrpeters-isl_ | a forum would make sure the popular (and likely most important) things would always be there at the top |
| # | 14:39:32 | bshum | kmlussier: I think that's right. Launchpad is unwieldy for the job you're describing. At least in its current form. |
| # | 14:39:36 | mrpeters-isl_ | by forum, i'm open to what dbs proposes |
| # | 14:40:00 | dbs | see http://fudforum.org/forum :) |
| # | 14:40:06 | kmlussier | We could take a look at that. |
| # | 14:40:21 | bshum | To move this along, perhaps we should Action Item that kmlussier (or member of web team) start a general discussion thread to gather further ideas from the community (in addition to what's been discussed so far). |
| # | 14:40:32 | dbs knows the dev behind fudforum, ilia |
| # | 14:40:45 | csharp googles 'mailman forum integration' |
| # | 14:40:58 | tspindler_ has joined #evergreen |
| # | 14:41:02 | kmlussier | Sure, I think put something back a while out (not specific to Launchpad), but I can put something out there again. |
| # | 14:41:31 | kmlussier | ^^ while ago, I mean. :-) |
| # | 14:41:37 | LBA has joined #evergreen |
| # | 14:41:38 | bshum | Okay. |
| # | 14:41:44 | brian_f_ has joined #evergreen |
| # | 14:42:12 | alynn26 | .0 |
| # | 14:42:14 | bshum | Moving on for now, unless there's anything else. |
| # | 14:42:17 | adbowling-isl_ has joined #evergreen |
| # | 14:42:33 | bshum | 5. Conference committee. Not sure if anyone else is here from that? |
| # | 14:42:58 | bshum | I know that sborger got a bunch of proposals for EG 2012, the programs committee is going to start reviewing them next week. |
| # | 14:43:17 | adbowling-isl_ | bshum: yes. looking for more if we can get them. |
| # | 14:43:29 | bshum | ^-- not too late dbs! |
| # | 14:43:30 | tspindler has quit IRC |
| # | 14:43:30 | brian_f has quit IRC |
| # | 14:43:38 | dbs | Dang |
| # | 14:43:54 | adbowling-isl_ | last i heard yesterday, we had 25 |
| # | 14:43:59 | adbowling-isl has quit IRC |
| # | 14:44:17 | adbowling-isl_ | am i still here? |
| # | 14:44:25 | moodaepo | adbowling-isl_: Yup! |
| # | 14:44:26 | csharp | adbowling-isl_: I see you |
| # | 14:44:28 | mrpeters-isl_ has quit IRC |
| # | 14:44:46 | mrpeters-isl has joined #evergreen |
| # | 14:44:49 | csharp | flaky web interface? |
| # | 14:44:55 | bshum | I had 36 in the list I got, but more the merrier |
| # | 14:45:01 | adbowling-isl_ | thanks. yeah. we're getting some nonsense here. |
| # | 14:45:30 | dbs | And the committee is looking for how many? |
| # | 14:45:39 | moodaepo feels we should stick to deadlines unless we are desperate for more or quality of proposals stink |
| # | 14:45:46 | adbowling-isl_ | dbs: 40, i believe |
| # | 14:46:00 | csharp | adbowling-isl_: we had the same problem last year with getting enough submissions. Extending the deadline and appealing to the lists brought us more than enought |
| # | 14:46:01 | adbowling-isl_ | that's what was told to me in a meeting yesterday, anyway |
| # | 14:46:09 | dbs knows his proposal stinks anyway :) |
| # | 14:46:15 | moodaepo | Making a exception for dbs of course is acceptable : ) |
| # | 14:46:17 | adbowling-isl_ | csharp: i thinks that's our route |
| # | 14:47:13 | adbowling-isl_ offers the hosting of demo servers for you in exchange for more proposal submissions |
| # | 14:47:48 | dbs | Any word on keynote speakers? |
| # | 14:47:56 | moodaepo | adbowling-isl_++ |
| # | 14:48:20 | dbs | (not looking for actual names, just if candidates have been firmed up) |
| # | 14:48:37 | mrpeters-isl | hosting -- not maintaining :), right adbowling-isl_ :) |
| # | 14:48:45 | pmpcat has joined #evergreen |
| # | 14:48:47 | adbowling-isl_ | dbs: think that's still a point of conversation, which is an academic way of saying "no" |
| # | 14:49:04 | dbs | :) |
| # | 14:49:32 | adbowling-isl_ | mrpeters-isl++, yes HOSTING, not MAINTAINING |
| # | 14:49:34 | bshum | Heh, okay |
| # | 14:50:04 | bshum | Well, if nothing else for now, let's move to 6. Documentation Interest Group |
| # | 14:50:42 | bshum | Didn't see anybody there, but maybe I'm wrong |
| # | 14:51:57 | bshum | Okay, deferred, we'll find out where DIG is later. |
| # | 14:52:07 | bshum | 7. Reports Taskforce |
| # | 14:52:37 | moodaepo | bshum: I don't see anyone either request an update via mail or just move on to next topic? |
| # | 14:52:40 | bshum | jenny wanted me to convey that notes are still being compiled from the last meeting, but: |
| # | 14:53:26 | bshum | PINES had to put their reports rewrite on hold, and jeff is doing cool stuff with JasperReports at TADL. |
| # | 14:53:35 | bshum | The next reports meeting is on 12/14, in IRC. |
| # | 14:54:09 | bshum | That's it for now, there. |
| # | 14:54:33 | bshum | 8. Developer Report (can see dbs has the fancy link to report going on) |
| # | 14:55:06 | bshum | Anything to add or questions for the developers? |
| # | 14:56:42 | moodaepo | Any thoughts/questions about EOL policy from non-dev people? |
| # | 14:56:51 | jamesrf | with respect to the EOL policy, is there an implicit timeline for releases? |
| # | 14:57:08 | jamesrf | ie: tying EOL to a release, what if 2.2 comes out 3 months after 2.1 |
| # | 14:57:27 | adbowling-isl_ | We have many thoughts on the EOL policy |
| # | 14:57:35 | csharp | seems the large consortia have some concerns about the policy |
| # | 14:57:44 | csharp | (as we're all speaking up at once ;-) ) |
| # | 14:57:45 | adbowling-isl_ | jamesrf raises one of many of our concerns |
| # | 14:58:05 | mrpeters-isl | Evergreen Indiana has significant concern about the proposed EOL policy. It's extremely tight for large consortia. |
| # | 14:58:06 | dbs advocates moving to time-based releases (every X months) so that those concerns can go away |
| # | 14:58:26 | jamesrf | basically large consortia need to plan upgrades, so we need to know a release is supported for X amount of time |
| # | 14:58:52 | csharp | give the logistics of upgrades, including downtime (3 days worth for our 1.6 - 2.1 upgrade), we can't upgrade any more than once per year, most likely |
| # | 14:59:02 | adbowling-isl_ | dbs: i think we can get behind that, but we need to have sufficient time between upgrades to do what jamesrf just references |
| # | 14:59:06 | mrpeters-isl | perhaps with more complete documentation for each release, large consortia could consider upgrading more regularly, however, it's difficult to upgrade more than once, or twice a year without signifcant outrage from our customers/member libraries |
| # | 14:59:19 | csharp | +1 to mrpeters-isl |
| # | 14:59:36 | jamesrf | +1 and signifigant outrage = negative opinions of evergreen |
| # | 14:59:50 | adbowling-isl_ | with 100 libraries in our consortia, we get killed for downtime as it is, without going more aggressive on upgrade timeline |
| # | 14:59:50 | dbs was thinking "every 6 months" for time-based releases, which would mean one upgrade required per year |
| # | 14:59:58 | adbowling-isl_ | jamesrf++ |
| # | 15:00:00 | dbs | but dbs is just one voice |
| # | 15:00:02 | graced | dbs++ |
| # | 15:00:09 | csharp | yes - in a contentious budget climate where many are itching to cut library funding :-/ |
| # | 15:00:22 | mrpeters-isl | i would LOVE to be able to run master and keep it up to date every day like some smaller groups do, but it's just too big of a moving target with documentation for new features lacking |
| # | 15:00:24 | tspindler_ | dbs++ |
| # | 15:00:26 | dbs does not like either outrage or negative opinions of evergreen |
| # | 15:00:43 | moodaepo | csharp: jamesrf: adbowling-isl_: As dbs says 6months would be my vote (since I've been looking at fedora quite a biot - http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle as an example) |
| # | 15:00:46 | mrpeters-isl | we're about to move to 2.1 and we're still struggling with some 2.0.4 features we've had to just "figure out" on our own |
| # | 15:01:41 | adbowling-isl_ | dbs: I don't think that's unreasonable, but i think that's the most aggressive we'd want to see it |
| # | 15:01:59 | csharp | and we've been spending all of our time trying to get the basics under control for our upgrade - we haven't had time or staff to delve into the shiny stuff ;-) |
| # | 15:01:59 | dbs | mrpeters-isl: if it makes you feel any better, we're in the same boat on some features - just starting to use bookings now, for example |
| # | 15:02:11 | mrpeters-isl | i know lots of us are, dbs |
| # | 15:02:17 | adbowling-isl_ | as mrpeters-isl states, it's like we're upgrading just when we have the last version figured out |
| # | 15:02:23 | mrpeters-isl | and i'm not putting blame anywhere specifically |
| # | 15:02:45 | jamesrf | heh. yeah sometimes feels like "it's finally stable! now let's upgrade!" |
| # | 15:02:51 | mrpeters-isl | i just think there should be a tradeoff where if we're going to go to faster EOL cycles, we need to make sure the new versions have ample documentation before the old ones are killed off. |
| # | 15:02:52 | csharp | jamesrf: yes! |
| # | 15:03:04 | mrpeters-isl | jamesrf +1 to that! |
| # | 15:03:18 | ElliotFriend | jamesrf +1 |
| # | 15:03:39 | mrpeters-isl gets in trouble a lot for that thought! |
| # | 15:03:40 | moodaepo notes that then there are those crazy run of bleeding edge monsters tsbere & Dyrcona : ) |
| # | 15:03:43 | dbs | on stability: I do think that our much more cautious approach to committing code since adopting git will change that experience fairly significantly |
| # | 15:04:02 | csharp | we need to be more Debian-like (slow and steady) than Ubuntu/Fedora-like (with more awesomeness but quickly) |
| # | 15:04:04 | moodaepo | *run off |
| # | 15:04:15 | Dyrcona | moodaepo: It was the only way we could get our members the functionality that they want. |
| # | 15:04:22 | adbowling-isl_ | csharp +1 |
| # | 15:04:34 | moodaepo | Dyrcona++ # I am with you sir |
| # | 15:04:36 | dbs | I concur completely that the "it takes X number of point releases to get to a stable release" was double-plus ungood. |
| # | 15:04:52 | jamesrf | +1 to mrpeters-isl, i'm wondering how the DIG feel about keeping up with releases? |
| # | 15:04:52 | dbs | (See also: dbs testing rambling in dev report) |
| # | 15:05:07 | mrpeters-isl | jamesrf: probably overwhelmed |
| # | 15:05:08 | adbowling-isl_ | our libraries want features, too, but if it's a features vs. stability scenario, they're gonna pick stability every time |
| # | 15:05:28 | mrpeters-isl | we |
| # | 15:05:39 | mrpeters-isl | are about to upgrade to 2.1, which as far as i can see, has no official documentation |
| # | 15:05:48 | mrpeters-isl | that scares me...a lot |
| # | 15:05:57 | dbs | Hey - there are release notes! |
| # | 15:06:00 | mrpeters-isl | and means i'll be in here annoying with questions daily for the next month |
| # | 15:06:14 | mrpeters-isl | dbs: it's not so much documentation for me, but rather for the customers |
| # | 15:06:16 | moodaepo | So this is what I'm hearing - EOL policy as proposed is acceptable if we decide to move to say 6 month major release cycle? |
| # | 15:06:27 | csharp | mrpeters-isl: I'm right there with you - we can take turns annoying ;-) |
| # | 15:06:58 | LBA | I'm wondering if there is something that needs to happen that would make writing documentation more manageable... |
| # | 15:06:59 | mrpeters-isl | moodaepo: i dont think we can put a timeframe on it without a tradeoff of making sure documentation is guranteed for new releases |
| # | 15:07:07 | csharp | so that means 18 months of bugfixes/support per release? |
| # | 15:07:11 | graced | LBA: like more volunteers? |
| # | 15:07:18 | dbs | moodaepo: and also sounds like "And DIG needs more volunteers to help keep up with current docs" |
| # | 15:07:18 | LBA | that would help |
| # | 15:07:29 | mrpeters-isl | for example, if we EOL 1.6...that needs to mean that documentation for 2.1 should be available |
| # | 15:07:45 | LBA | but is there something MORE than release notes that devs could provide that would help the volunteers? I don't know, just asking. |
| # | 15:07:46 | adbowling-isl_ | moodaepo: I don't know that 6 months is entirely crazy, but it's going to put me a little on edge. if we can stick to timeline with the assertion that we will have documentation, too, I will feel more comfortable |
| # | 15:07:48 | dbs thinks AsciiDoc would be more approachable... |
| # | 15:07:49 | mrpeters-isl | graced: more volunteers are good, but even still, it has to start with the people who write the code |
| # | 15:08:11 | mrpeters-isl | give a bit of a framework for those non-developer types to run with |
| # | 15:08:14 | graced | mrpeters-isl: I actually think the quality of the release notes has really improved |
| # | 15:08:31 | mrpeters-isl | for example, EDI -- bshum and I were completely lost on it when we started our documentation |
| # | 15:08:34 | adbowling-isl_ | i should note, all that said, i do actually think a fixed timeline is a good thing, too |
| # | 15:08:56 | mrpeters-isl | there was about a 3 sentence README that we would never have found without a dev telling us where it was burried |
| # | 15:08:56 | tspindler_ | mrpeters-isl: i'm still lost |
| # | 15:08:58 | LBA | graced, is there another step more that needs to happen. wish the DIG folks were here to comment. |
| # | 15:09:03 | moodaepo | mrpeters-isl: I hear you but without shelling out monies or finding volunteers documentations is not going to happen. Also folks who contract with developers need to stress that documentation be provided to DIG when code is released. |
| # | 15:09:21 | adbowling-isl_ | what i don't want is to get into a fixed timeline = rush to release scenario, then we're back to where we are/have been |
| # | 15:09:29 | csharp | the other concern we have is the actual length of time it takes to upgrade our system (another large consortium issue) |
| # | 15:09:32 | mrpeters-isl | if you can take the time to write the code, why cant you take the time to write the documentation? |
| # | 15:09:49 | csharp | in this case, the upgrade process (best case) is 60 hours |
| # | 15:09:51 | mrpeters-isl | don't rush out a new release just to get it out. get the last release done, documented, etc. and then move on |
| # | 15:09:52 | dbs knows that Karen of DIG can't make any Fridays - maybe try a different day for next community meeting and make "How can we the community help DIG with docs?" |
| # | 15:10:01 | phasefx_ isn't a technical writer, fwiw :) |
| # | 15:10:25 | mrpeters-isl | point im trying to get to is, don't release a new version without the documentation being ready to ship along with it |
| # | 15:10:41 | moodaepo | mrpeters-isl: Customers need to make it part of the contract, developers being busy will move from one gig to another..is what I'm guessing |
| # | 15:10:44 | mrpeters-isl | if bleeding edge people need to upgrade to get a new feature, then let that be their individual decision to make |
| # | 15:10:47 | LBA | csharp, how does Debian do it? Who writes the documentation? Or, what do we know about the handoff between developers and technical writers/DIG? |
| # | 15:10:57 | kmlussier | I think volunteers/time to write the documentation is a big issue with DIG (speaking as somebody who has volunteered for DIG, but never finds enough time to devote to documentation.) |
| # | 15:10:59 | Dyrcona | debian has documentation? |
| # | 15:11:03 | graced | dbs: I think you're right, we need to be able to get Karen in to really discuss how to make it easier for DIG |
| # | 15:11:13 | csharp | LBA: Debian doesn't have great documentation |
| # | 15:11:15 | csharp | ;-) |
| # | 15:11:16 | kmlussier | But I would hate to wait until documentation is written before a release is pusehd out. |
| # | 15:11:39 | csharp | LBA: I think postgresql might be a better project to look to in that regard |
| # | 15:11:41 | dbs +1s what phasefx_ said. Some people are good at writing, some people are good at code, some are good at testing. (/me hides his previous tech writer career) We need to figure out how to work together to maximize our strengths |
| # | 15:11:48 | tspindler_ | kmlussier: personally, I write documentation when I have an itch to scratch and my guess others do so it is not comprehensive |
| # | 15:11:52 | LBA | yea, don't want to hold code hostage but would like to improve the flow from dev to documented |
| # | 15:12:12 | mrpeters-isl | kmlussier: nothing stops you from upgrading on your own....but putting an old release to its grave before documentation for the release the community says you have to upgrade to is silly |
| # | 15:12:37 | adbowling-isl_ doesn't want to get through our 2.0.4 experience again |
| # | 15:12:50 | adbowling-isl_ | *go |
| # | 15:13:00 | LBA | mrpeters-isl advocates not EOL the old release until the current one is adequately documented? |
| # | 15:13:02 | csharp | what we need is a "middle layer" - people who understand the software and can communicate about it (and have the time) |
| # | 15:13:15 | mrpeters-isl | things are improving, but why do we have to rush into killing off old releases |
| # | 15:13:20 | phasefx_ | so, for every code change, a launchpad ticket, that tracks the lifecycle of the feature.. comments, implementation, testing, documentation, release |
| # | 15:13:27 | dbs hates to mention this, but not making the DIG jump through licensing hurdles would probably help get some 2.1 docs in place |
| # | 15:13:45 | kmlussier | dbs++ |
| # | 15:14:42 | mrpeters-isl just hates feeling around in the dark when a big new feature is out |
| # | 15:15:42 | phasefx_ | to follow up on that, it may be perception at this point. My understanding is that DIG gets Equinox documentation under the desired license, CC-BY-SA. They're just the first party to get it such |
| # | 15:15:49 | adbowling-isl_ and mrpeters-isl are still recovering from the 2.0.4 upgrade we did in march; the scars are finally starting to fade |
| # | 15:15:49 | dbs | phasefx_: we're getting closer to that with tickets for (almost) every branch to merge, requiring sign-off, targeting specific releases -- adding "documentation" and "test cases" to the review/sign-off would kind of get us there |
| # | 15:16:01 | ElliotFriend | csharp +1 |
| # | 15:16:33 | LBA | phase_fx++ |
| # | 15:16:45 | adbowling-isl_ | csharp +1: imo, that's Evergreen's biggest weakness |
| # | 15:16:55 | moodaepo | How about a release with documentation is made available in addition to the current policy. This will not receive any new features or fixes (?) |
| # | 15:16:59 | dbs | phasefx_: sorry, where does the DIG get this Equinox documentation? Where is the CC-BY-SA license visible? |
| # | 15:17:11 | mrpeters-isl | dbs: even just including a few sentences with each commit message, that the developer writes, which are marked for inclusion in the release notes |
| # | 15:17:29 | adbowling-isl_ | we have good coders. we have good communicators. we don' t seem to have a good interface to bridge those two. |
| # | 15:17:49 | mrpeters-isl | "This branch adds this new feature, here's the basics, etc." and then that always gets plucked out for the release notes |
| # | 15:18:35 | mrpeters-isl | may make for long release notes, but at least then EVERY new feature will be acknowledged in the notes so sys admin's know to work on configuring them, assiging internal documenters, etc. |
| # | 15:18:50 | csharp | if we had a QA division that could pass rough documentation to DIG, that might help |
| # | 15:19:14 | phasefx_ | dbs: I'm personally not a fan of how that played out, but Equinox "gave license" in one or more emails. It's a standing license. It's just the same license as what goes up with the content on the Equinox website |
| # | 15:19:15 | dbs | mrpeters-isl: Have you run "git log" against master recently? We're way better than we used to be. But auto-plucking release notes from commit logs would be way messy. |
| # | 15:19:17 | graced | csharp: that's a good idea, I like it |
| # | 15:19:30 | phasefx_ | s/just/just not/ |
| # | 15:19:40 | csharp wishes he had more time to do that for the community |
| # | 15:20:10 | mrpeters-isl | it is better, i agree. i just think the release notes for each new feature deserve more than a 1 line title |
| # | 15:20:24 | greg-g has joined #evergreen |
| # | 15:20:32 | adbowling-isl_ agrees with csharp. we have 2.5 guys (I being the half) dedicated to Evergreen for the entire state of Indiana. |
| # | 15:20:42 | bshum | csharp: Amen. I feel that everybody volunteers as best they can, but it's hard to coordinate sometimes. |
| # | 15:20:48 | dbs | phasefx_: I saw "DIG just needs to ask us for a license"; a link to an email granting a CC-BY-SA license that applies to all versions of Equinox docs that appear in some specific location would be awesome |
| # | 15:20:57 | Dyrcona | mrepeters-isl: Do I hear you volunteering to write documentation? |
| # | 15:21:13 | moodaepo | Dyrcona++ ; ) |
| # | 15:21:36 | mrpeters-isl | commit 02211d5c48e703e691564c69b6ef42a98f5e15b6 is an excellent example of, what i'd consider, good starter documentation |
| # | 15:21:41 | phasefx_ | dbs: I'll poke folks into providing something unambigious and easily referenceable |
| # | 15:21:50 | dbs | phasefx_++ |
| # | 15:21:52 | dbs | phasefx_++ |
| # | 15:21:52 | dbs | phasefx_++ |
| # | 15:22:23 | jamesrf | senator++ |
| # | 15:22:26 | mrpeters-isl | Dyrcona: man, i wrote almost all of our documentation solo when we first joined Evergreen. Then our trainers and members just expanded upon it. |
| # | 15:22:59 | mrpeters-isl | http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=02211d5c48e703e691564c69b6ef42a98f5e15b6 --- great |
| # | 15:23:12 | moodaepo | mrpeters-isl++ |
| # | 15:23:39 | jamesrf wonders if we're getting a bit off topic from release/EOL policy? |
| # | 15:23:54 | mrpeters-isl | perhaps, jamesrf |
| # | 15:23:58 | bshum | Well, I don't want to stop the discussion, but I think we should complete the current Community Meeting and then continue if desired on how this should work. Ideally, I think this topic is big enough to warrant further discussion elsewhere as well. Lists or special meeting in IRC later, or even at the conference. |
| # | 15:23:59 | moodaepo | Ok we still need a resolution on this too bad mrpeters-isl missed the dev meeting so we could have had ideas to bring to this meeting. |
| # | 15:24:04 | LBA | related and important though |
| # | 15:24:14 | jamesrf | agreed |
| # | 15:24:26 | mrpeters-isl | moodaepo: sorry -- i usually try to make it but we've been in meltdown mode this week preparing for 2.1 |
| # | 15:24:27 | adbowling-isl_ doesn't disagree with jamesrf, but feels this all related |
| # | 15:25:50 | alynn26 | . |
| # | 15:25:53 | alynn26 | . |
| # | 15:25:54 | alynn26 | . |
| # | 15:25:55 | alynn26 | . |
| # | 15:25:55 | alynn26 | . |
| # | 15:25:56 | alynn26 | . |
| # | 15:25:56 | alynn26 | . |
| # | 15:25:57 | alynn26 | . |
| # | 15:25:57 | alynn26 | . |
| # | 15:25:58 | alynn26 | . |
| # | 15:25:58 | alynn26 | . |
| # | 15:25:59 | alynn26 | . |
| # | 15:25:59 | alynn26 | . |
| # | 15:26:00 | alynn26 | . |
| # | 15:26:00 | alynn26 | . |
| # | 15:26:01 | alynn26 | . |
| # | 15:26:01 | alynn26 | . |
| # | 15:26:02 | alynn26 | . |
| # | 15:26:02 | alynn26 | . |
| # | 15:26:04 | jamesrf | stop that |
| # | 15:26:05 | bshum | Hmm |
| # | 15:26:14 | alynn26 | . |
| # | 15:26:14 | alynn26 | . |
| # | 15:26:15 | alynn26 | . |
| # | 15:26:15 | alynn26 | . |
| # | 15:26:18 | adbowling-isl_ | i speak, I know, for our consortium when I say that we're not comfortable voting on any EOL policy without beefing up the documentation and providing contingency for what happens when that documentation is not ready |
| # | 15:26:20 | LBA | someone leaning on their keyboard. Cat |
| # | 15:26:53 | bshum | Well, how about this then. |
| # | 15:27:03 | moodaepo | LBA++ Blame it on the poor cat! |
| # | 15:27:31 | alynn26 | no, christmas cards:) |
| # | 15:27:49 | adbowling-isl_ | a cat that's coordinated enough to alternate between one period and the Enter key, no less |
| # | 15:28:04 | bshum | Since we're having another developer meeting next Tuesday (theoretically) we should re-open teh topic for further consideration at least then. |
| # | 15:28:14 | adbowling-isl_ | bshum: i think so |
| # | 15:28:18 | moodaepo | +1 |
| # | 15:28:25 | bshum | And invite all those interested to participate. |
| # | 15:28:39 | mrpeters-isl | to be fair on the EOL thing, it's fair to say that I think all of us would be willing to still help someone who had problems with a end of life release |
| # | 15:28:40 | dbs | bshum++ |
| # | 15:28:41 | rwalsh | what time is the dev meeting on Tues? |
| # | 15:28:45 | bshum | 1.6 is already dead, but the priority here is to develop a proper EOL strategy for the future. |
| # | 15:28:50 | mrpeters-isl | just don't expect new code/features/big bug fixes |
| # | 15:29:13 | bshum | By "dead" yes, I meant what mrpeters-isl said about new code/features/big bug fixes |
| # | 15:29:15 | moodaepo | mrpeters-isl: Exactly and there are always vendors |
| # | 15:29:20 | mrpeters-isl stops talking now |
| # | 15:29:21 | phasefx_ | or heavy backporting |
| # | 15:29:33 | bshum | The dev meeting is normally scheduled for 12 pm EST on every other Tuesday |
| # | 15:29:35 | adbowling-isl_ | phasefx_: agreed to that too |
| # | 15:29:36 | moodaepo | mrpeters-isl: Finally! : ) |
| # | 15:29:46 | bshum | So if we stick to that, it's December 13th, 12 pm EST |
| # | 15:29:49 | mrpeters-isl | oh, moodaepo, i've always known that |
| # | 15:30:20 | bshum | If you cannot attend, I would strongly suggest that you clarify your thoughts on the lists and we'll bring those with us to the meeting as well. |
| # | 15:30:34 | mrpeters-isl | my fear just would be a vendor pushing us into an upgrade when we're not prepared because it becomes cumbersome to continue supporting the current version we may be on |
| # | 15:30:47 | adbowling-isl_ | bshum++ |
| # | 15:30:52 | bshum | For now, we'll action item this as a topic for further discussion to report back at the next Community Meeting. |
| # | 15:31:05 | bshum | I'll take that action item to write a report summary, moodaepo |
| # | 15:31:11 | tater-laptop has joined #evergreen |
| # | 15:31:16 | bshum | For the next community meeting that is :) |
| # | 15:31:21 | adbowling-isl_ | sounds very prudent to me |
| # | 15:31:50 | bshum | The last two items on our agenda today, was the governance report and scheduling for the next Community Meeting. |
| # | 15:32:08 | LBA | one more quick thing from Communications Committee (sorry I was late) |
| # | 15:32:18 | bshum | Sure LBA, go ahead. |
| # | 15:32:50 | LBA | I just pasted a draft set of Participation Guidelines for Evergreen Communication Channels. |
| # | 15:33:08 | LBA | Would like to encourage people to review and comment. |
| # | 15:33:35 | LBA | If no objections, we'll start sharing those guidelines on website and on mailing lists. |
| # | 15:33:48 | LBA | Can someone release my paste....? |
| # | 15:34:02 | bshum | I'm not seeing it |
| # | 15:34:11 | LBA | operator error...now it should be there |
| # | 15:34:19 | bshum | http://paste.lisp.org/display/126246 |
| # | 15:34:21 | bshum | There we go |
| # | 15:34:24 | moodaepo | Proposed Communication Guidelines ^^ |
| # | 15:35:02 | LBA | thanks to June Rayner of EINetwork for drafting this.... |
| # | 15:35:02 | bshum | Seems reasonable, though I would note somewhere that IRC may be quiet at times. |
| # | 15:35:17 | bshum | Given questions we've taken in the past month from India and other timezones. |
| # | 15:35:26 | LBA | bshum, good point. |
| # | 15:35:45 | bshum | And also, people wander in and out of IRC more informally. |
| # | 15:35:47 | dbs | LBA: so, the Launchpad Blueprints suggestion might be tabled pending kmlussier's topic |
| # | 15:36:01 | bshum | So if they don't get an answer right away, it's not that we're ignoring them. |
| # | 15:36:07 | bshum | Well, not necessarily.... :) |
| # | 15:36:32 | bshum | But I've found that often folks chime in when they can. |
| # | 15:36:39 | LBA | launchpad is for bugs. percolater....we're still working on that. so we didn't mention it in the guidelines |
| # | 15:36:47 | phasefx_ | might be worth encouraging folks to follow-up to a query that was started on list and got answered later in IRC (or otherwise off-list) |
| # | 15:36:58 | dbs | LBA: last line says "Add details about a development project in progress to a Launchpad blueprint." |
| # | 15:37:08 | LBA | phasefx_ thanks, good idea. |
| # | 15:37:21 | mrpeters-isl has quit IRC |
| # | 15:37:32 | phasefx_ | iow, however you found the answer, share it |
| # | 15:37:34 | LBA | dbs, that is right, isn't it? Regardless of our percolator/wish list stuff? |
| # | 15:37:47 | LBA | phasefx_ right, will do. |
| # | 15:38:03 | Dyrcona | no one is using launchpad blueprints as far as I know. |
| # | 15:38:15 | bshum | Dyrcona: At least two were at some point |
| # | 15:38:16 | dbs | maybe our "Chat" page could also mention how the @later plugin works |
| # | 15:38:17 | bshum | But |
| # | 15:38:25 | dbs | yeah, blueprints are pretty much dead |
| # | 15:38:27 | LBA | should we just dump the refernce to blueprints? |
| # | 15:38:40 | bshum | I think the discussion earlier suggested that using mailing lists are pretty standard approach for new development project ideas. |
| # | 15:39:04 | bshum | At least to get started. |
| # | 15:39:04 | kmlussier | bshum: I don't think we said mailing lists, just not Launchpad. |
| # | 15:39:05 | LBA | dev and gen mailing lists? |
| # | 15:39:54 | bshum | kmlussier: You're probably right, my memory's fuzzy from an hour ago already :S |
| # | 15:40:08 | kmlussier | bshum++ It is getting late! :-) |
| # | 15:40:22 | dbs | Best... Community Meeting... EVER! |
| # | 15:40:27 | phasefx_ | :D |
| # | 15:40:37 | bshum | Okay, well, I think LBA should solicit any additional suggestions from the general list about the participation guidelines |
| # | 15:40:41 | Dyrcona | :) |
| # | 15:40:48 | LBA | thanks, all! |
| # | 15:40:50 | bshum | But I'm generally +1 in favor of them (with the noted observations) |
| # | 15:41:11 | bshum | Since the governance report is a link, we'll just use that. |
| # | 15:41:24 | bshum | And I'd like to move to schedule the next Community Meeting. |
| # | 15:41:37 | moodaepo | bshum++ |
| # | 15:41:47 | dbs | January 1 |
| # | 15:41:52 | moodaepo | dbs++ |
| # | 15:42:06 | bshum | That's a Sunday isn't it? |
| # | 15:42:15 | moodaepo | January 9th so Karen can make it to the meeting? |
| # | 15:42:19 | csharp | heh |
| # | 15:42:22 | dbs | bshum: Have you no commitment to the project? :) |
| # | 15:42:28 | moodaepo | bshum: Not in India |
| # | 15:42:35 | bshum | I actually won't be here the first two weeks of January |
| # | 15:42:39 | bshum | Well, week and a half. |
| # | 15:42:55 | moodaepo | Depending what time it is set...should've gone with NZ |
| # | 15:43:14 | dbs bets not much will happen in the last two weeks of December and the first two weeks of January, and that plenty of people will be away |
| # | 15:43:33 | moodaepo wouldn't mind Jan 16th |
| # | 15:43:37 | bshum | Perhaps we should aim for a mid-January meeting then |
| # | 15:43:42 | dbs | +1 to January 16th |
| # | 15:43:57 | bshum | That's Martin Luther King Day, apparently. |
| # | 15:44:01 | csharp | that's MLK |
| # | 15:44:03 | bshum | American holidays |
| # | 15:44:17 | csharp | and our soft go-live on 2.1 |
| # | 15:44:46 | csharp | (not that our upgrade date should influence scheduling ;-) ) |
| # | 15:45:05 | bshum remembers going to a community meeting during our migrations too. |
| # | 15:45:12 | moodaepo | csharp++ |
| # | 15:45:15 | bshum | Step it up csharp! |
| # | 15:45:18 | bshum | :) |
| # | 15:45:20 | csharp | heh |
| # | 15:45:21 | moodaepo | How about the 18th? |
| # | 15:46:03 | moodaepo | Jan 18th going once. |
| # | 15:46:08 | bshum | +1 for me |
| # | 15:46:17 | bshum | But let's make sure we can get Karen from DIG there. |
| # | 15:46:50 | bshum | Or someone from DIG rather. |
| # | 15:46:58 | moodaepo | bshum: Set the date and if she can't update on mailing list? |
| # | 15:47:01 | collum has quit IRC |
| # | 15:47:16 | bshum | Sounds good. Let's tentatively schedule for January 18th, barring unforeseen issues. |
| # | 15:47:34 | bshum | Reminders will go out in the weeks leading up, we can reposition then as necessary. |
| # | 15:47:44 | phasefx_ | +1 |
| # | 15:47:55 | jamesrf | that's Diefenbaker Day. Canadian holiday. |
| # | 15:47:55 | bshum | If there's nothing else for now, thanks for all the participation today folks, and have a great weekend all! |
| # | 15:47:58 | jamesrf | jk |
| # | 15:48:16 | bshum | jamesrf++ :) |
| # | 15:48:18 | moodaepo | Longest community meeting ever! |
| # | 15:48:20 | jamesrf | also no intent to compare Diefenbaker to MLK |
| # | 15:48:22 | moodaepo | jamesrf++ |
| # | 15:48:27 | bshum | No that was about mid-range |
| # | 15:48:32 | bshum | I think the longest was over 2 hours |
| # | 15:48:43 | bshum | I'd have to check the past meeting notes moodaepo |
| # | 15:48:50 | kmlussier | bshum++ for getting us through that agenda! |
| # | 15:48:51 | moodaepo | I tend to blot them out so you might be right |
| # | 15:49:35 | jamesrf | bshum++ |
| # | 15:50:05 | bshum | Dyrcona++ for filling my inbox with bug tracking updates |
| # | 15:50:30 | Dyrcona | bshum: Don't you filter them to a special folder? |
| # | 15:50:41 | mmorgan has joined #evergreen |
| # | 15:50:57 | bshum | Dyrcona: I should start doing that. |
| # | 15:54:09 | dbs usually wants to see all bug report updates immediately, but on days like these :) |
| # | 15:56:02 | dbs | also, there are brand new bug reports that have been opened in the last hour |
| # | 15:56:05 | tspindler_ has quit IRC |
| # | 15:56:26 | Dyrcona | well, I think I'm done for the day. That last change may have been a mistake, so I'll quit before I make too many more. |
| # | 15:56:32 | jamesrf | dbs: do you know what ever happened with you and jeff's added content-based on recordids hackfest project? |
| # | 15:57:16 | kmlussier has quit IRC |
| # | 15:57:29 | Meliss has quit IRC |
| # | 15:57:37 | dbs | jamesrf: that was all jeff doing the code, I was just a plush toy he was talking to - but I nagged him about it recently and he said he would try to get it into a branch somewhere |
| # | 15:58:06 | dbs | (because I want bib-id based added content but don't want to rewrite what was already written) |
| # | 15:58:26 | dbs | Down with ASINs in ISBN fields! |
| # | 15:58:42 | bshum | I'm waiting on that branch too, jeff. |
| # | 15:58:48 | bshum | Jeff's got all the cool toys. |
| # | 16:01:56 | jamesrf | yeah we need to find a way to do mutliple providers |
| # | 16:02:09 | tater-laptop has quit IRC |
| # | 16:02:15 | tater-laptop has joined #evergreen |
| # | 16:03:31 | jenny has left #evergreen |
| # | 16:08:54 | plux has quit IRC |
| # | 16:26:44 | mdevilz has quit IRC |
| # | 16:34:06 | dbs has quit IRC |
| # | 16:41:34 | _bott_ has quit IRC |
| # | 16:41:55 | gmcharlt | adbowling-isl_: fyi, I've got conference.evergreen-ils.org set up as a CNAME for evergreen2012.org, but looks like the vhost config on that webserver's end needs to be adjusted |
| # | 16:42:06 | _bott_ has joined #evergreen |
| # | 16:42:44 | matt_carlson has joined #evergreen |
| # | 16:43:13 | ElliotFriend has quit IRC |
| # | 16:44:01 | bshum changes topic to "The topic for #evergreen is: Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://pastebin.ca or http://paste.lisp.org/new/evergreen or something like that" |
| # | 16:44:08 | bshum | Oops, always forgetful :( |
| # | 16:46:56 | tater-laptop has quit IRC |
| # | 16:49:18 | dzho has joined #evergreen |
| # | 16:54:21 | bshum | @later tell dbs New proposals deadline of Dec 16, plenty more time to procrastinate in your PG tips/admin thoughts ;) |
| # | 16:54:21 | pinesol_green | bshum: The operation succeeded. |
| # | 16:54:44 | dkyle has left #evergreen |
| # | 16:59:39 | matt_carlson has quit IRC |
| # | 17:04:09 | AaronZ-PLS has quit IRC |
| # | 17:07:31 | mmorgan has left #evergreen |
| # | 17:27:29 | graced has quit IRC |
| # | 17:34:26 | graced has joined #evergreen |
| # | 17:39:01 | wjr has quit IRC |
| # | 17:39:40 | StephenGWills has quit IRC |
| # | 17:40:49 | pmpcat has quit IRC |
| # | 17:50:31 | wjr has joined #evergreen |
| # | 18:03:08 | akilsdonk has quit IRC |
| # | 18:56:55 | wjr has quit IRC |
| # | 19:14:15 | graced has quit IRC |
| # | 19:58:07 | Dyrcona has quit IRC |
| # | 20:04:01 | bshum changes topic to "Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://pastebin.ca or http://paste.lisp.org/new/evergreen or something like that" |
| # | 20:11:58 | rwalsh has left #evergreen |
| # | 20:37:49 | brian_f_ has quit IRC |
| # | 20:47:30 | artunit_ has joined #evergreen |
| # | 20:49:35 | artunit has quit IRC |
| # | 20:49:37 | artunit_ is now known as artunit |
| # | 23:22:36 | adbowling-isl_ has quit IRC |
April 10-13