13:03:08 <kmlussier> #startmeeting 2012-12017 Developer meeting
13:03:08 <pinesol_green> Meeting started Mon Dec 17 13:03:08 2012 US/Eastern.  The chair is kmlussier. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:03:08 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:03:26 <kmlussier> #topic Who's here
13:03:36 <Dyrcona> #info Jason Stephenson, MVLC
13:03:37 <berick> #info Bill Erickson / Equinox
13:03:38 <bshum> #info bshum is Benjamin Shum, Bibliomation
13:03:57 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC
13:04:02 <DPearl> DPearl is Dan Pearl, C/W MARS
13:04:12 <jeff> #info jeff is Jeff Godin, Traverse Area District Library (TADL)
13:04:13 <denials> #info denials is Dan Scott, Laurentian University
13:04:17 <paxed> #info paxed is Pasi Kallinen, Regional Library of Joensuu
13:04:19 * kmlussier can only run the meeting until 1:30, at which time she will hand it over to bshum.
13:04:23 <dbwells> #info Dan Wells, Calvin College
13:04:23 <phasefx> #info Jason Etheridge / Equinox
13:04:24 <artunit> artunit is Art Rhyno, U. of Windsor
13:04:30 <bshum> kmlussier++
13:05:02 <remingtron> #info Remington Steed, Calvin College
13:05:14 <eeevil> #info Mike Rylander / Equinox
13:05:21 <denials> kmlussier++ bshum++
13:05:51 <kmlussier> People can keep introducing each other into the next topic.
13:06:00 <kmlussier> #topic Action Items from Last Meeting
13:06:20 <kmlussier> Draft summary of “how we handle security-related bugs” and disseminate through appropriate channels. Was that jeff?
13:06:36 <gmcharlt> #info Galen Charlton /Equinox
13:06:37 <jeff> As linked in the agenda, I've drafted http://evergreen-ils.org/dokuwiki/doku.php?id=dev:security and posted to the dev list soliciting feedback and/or edits. Please take a look. I did my best to summarize the current process.
13:06:49 <bshum> #link Meeting Agenda:  http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2012-12-17
13:07:02 <bshum> (I'll spruce it up after the meeting to have our usual headers)
13:07:07 <kmlussier> bshum++ Thanks for helping me out! :)
13:07:40 <denials> jeff++
13:08:33 <kmlussier> #info jeff has drafted How the Evergreen Project Handles Security-Related bugs at http://evergreen-ils.org/dokuwiki/doku.php?id=dev:security
13:08:35 <jeff> edits in the wiki, feedback either on the dev list or via email to me. thanks!
13:08:52 <berick> jeff++
13:09:02 <bshum> jeff++
13:09:19 <kmlussier> #info Send feedback via dev list or make direct edits to wiki.
13:09:37 <kmlussier> jeff++
13:09:48 <kmlussier> Is edoceo around for an update on a Dojo test server?
13:10:47 <kmlussier> OK, I can't do an update of coordination on Dojo testing until a Dojo server is in place.
13:11:15 <kmlussier> Which leaves just one action item. To edit the TPAC plan wiki page and create appropriate bug links if necessary
13:11:19 <tsbere> #info tsbere is Thomas Berezansky, MVLC
13:11:29 * tsbere is paying too much attention to code, apparently
13:11:58 <kmlussier> Which I have done. bshum and I have also added jspacremovalblocker where we thought they were needed.
13:12:11 <bshum> I actually added jspacremovalblocker to all of those bugs
13:12:23 <bshum> But we need to decide if they really block us moving forward or not
13:12:31 <ktomita> #info Kyle Tomita / Catalyst IT
13:12:47 <kmlussier> bshum: Ahhh, I only added them to ones I thought were blockers.
13:12:50 <bshum> I figured tags were cheap, we could do more looking it over.
13:13:17 <jdouma> #info jdouma is Justin Douma, Catalyst IT
13:13:18 * bshum would be happy to undo tag additions.
13:13:43 <kmlussier> The list of missing jspac features is now pulled out in a separate section at http://evergreen-ils.org/dokuwiki/doku.php?id=dev:opac:template-toolkit:plan.
13:14:14 <kmlussier> Do we need to have further discussion on which of these bugs are true blockers?
13:15:12 <denials> kmlussier: sounds like yes?
13:15:57 <Dyrcona> I'd say we do.
13:16:02 <denials> (that's assuming that bshum tagged "Spell check" as a blocker just because it was on the list, as I would strongly argue against that being a blocker)
13:16:14 * kmlussier wonders if we need two different tags.
13:16:14 <eeevil> I think yes.  since the plan was to kill jspac for 2.4, I'll use that wikipage (kmlussier++) as the see for a discussion on the general list
13:16:29 * tsbere thinks that only one or two of the items in that list should be blockers, but may be abnormal in that regard
13:16:34 <denials> yeah, great work pulling that list together kmlussier
13:16:35 <kmlussier> One to clearly identify the missing jspac features and another to identify blockers.
13:16:53 <Dyrcona> I was going to say more or less what tsbere said, but we're not using JSPAC now.
13:16:53 <bshum> kmlussier: I think that sounds better, and I should have done so when going through bugs.  I'll take an action item to rectify that.
13:17:19 <Dyrcona> Yeah, that sounds good to me.
13:17:21 <kmlussier> bshum: Ok, so how about if we move to the two bugs and then have the further discussion on the general list?
13:17:22 <denials> Perhaps an action item is for other members of the community to go through the list and opine if they feel strongly one way or another about a bug being a blocker?
13:17:24 <Dyrcona> kmlussier++
13:17:55 <jeff> kmlussier++
13:18:38 <kmlussier> #action bshum will remove jspacremovalblocker from bugs that are not blockers and kmlussier will send message to general list to ask people to identify blockers.
13:19:06 <kmlussier> Anything else on previous action items?
13:19:29 <eeevil> kmlussier: I'll take the discussion-starting action, if you like
13:19:30 <kmlussier> #topic GSoC reports - Will anything from the GSoC projects land in 2.4?
13:19:42 <kmlussier> eeevil++ I'm happy to hand it over.
13:19:59 <kmlussier> But I have no idea how to amend the action.
13:20:14 <denials> Re: gsoc & 2.4: Dojo 1.6, I guess, if we get through some testing and hit a 2.4 deadline
13:21:20 <kmlussier> #action bshum will remove jspacremovalblocker from bugs that are not blockers and eeevil will send message to general list to ask people to identify blockers.
13:22:01 <kmlussier> denials: Other than dojo, are there other GSoC projects that need to be merged?
13:23:45 <denials> kmlussier: there were some of Sy's optimization efforts, not sure where those ended up
13:24:16 <kmlussier> #chair bshum
13:24:16 <pinesol_green> Current chairs: bshum kmlussier
13:24:25 <denials> And there was the PHP OpenSRF library, which may at least be worth a mention in docs & dev wiki topics to prevent yet another iteration being started from scratch
13:25:12 <kmlussier> eeevil: Is there anything from Sy's project that can be used?
13:25:42 <eeevil> kmlussier: not in its current state ...
13:25:52 <denials> Not sure if Daniel Rizea's android client effort should be in the main repo but again we should at least point people at where it lives & encourage people to build on it. dbwells might have a better idea about the appropriateness of that
13:25:55 <kmlussier> For the Dojo project, I guess we need the status for the Dojo testing server to know the likelihood of it hitting 2.4.
13:27:14 <denials> I guess, if we do the GSoC thing again & are lucky enough to get in, we need to do a better job on our side of getting the new devs' code integrated or called out where it is most useful.
13:27:24 <kmlussier> Is there anyone who would be willing to document the PHP work? Or maybe I should add it as an agenda topic for DIG.
13:28:03 <jeff> Would it be appropriate to ensure that the php and android code is in repositories on git.evergreen-ils.org, if it does not make sense to roll it into the main repos?
13:28:05 <kmlussier> Sorry to chair and run, but I have another meeting I need to get it.
13:28:13 <jeff> kmlussier++ thanks!
13:28:17 <kmlussier> It's all yours bshum!
13:28:19 <gmcharlt> jeff: yes
13:28:30 <denials> kmlussier++
13:28:45 <eeevil> +1 # repo at git.eg-ils.org
13:28:52 <dbwells> concerning the Android app project, it isn't ready for merging, and since its development is mostly parallel to Evergreen rather than deeply embedded, I don't see a big benefit to rushing it.  That said, it would be nice to increase awareness somehow.
13:28:54 <eeevil> kmlussier++
13:29:27 <jeff> It would be unfortunate for the community to lose that code should the GSoC students move on and one day clean house and delete their repo from github, say.
13:29:51 <berick> http://git.evergreen-ils.org/?p=working/random.git;a=summary
13:29:58 <Dyrcona> One of us could always fork it and/or move it.
13:30:16 <dbwells> I know there is some low hanging fruit in the Android code
13:31:01 <denials> berick: techically, yes, although I worry a tad about honoring the student's efforts by tossing it into a repo named "random" - heh
13:31:34 <Dyrcona> I'd be willing to fork them on github at a minimum.
13:31:37 <denials> #action denials to add a mention in the docs about PHP & Android efforts
13:31:58 <dbwells> denials++
13:32:11 <tsbere> technically you can use "start with an empty folder and push to the Evergreen working repo" as an alternative....though that can be odd when switching branches and your entire evergreen codebase vanishes.
13:32:22 <berick> yeah, toss it somewhere more appropriate, but since that hasn't happened... somebody toss it into random ;)
13:33:01 <bshum> Could we ask that the mentors assist with moving any related code into repositories and work with our git admins to setup repos as necessary then?
13:33:22 <bshum> I'd be happy to help as far as I could, but would hope that the mentors have an idea of what code is around and should get moved in.
13:34:01 <eeevil> bshum: sounds good to me (my student pushed to our repo, though, so I have it easy ;)  )
13:34:10 <Dyrcona> What's the repo for the Android work? Is it on github, too?
13:34:55 <dbwells> Actually, it is already in working.  Not sure if the code location makes perfect sense, but at least it is safe: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/drizea/android
13:35:27 <Dyrcona> Ah. Ok.
13:36:09 <bshum> #action GSOC_mentors to ensure related project code is moved to Evergreen git repos.
13:37:59 <bshum> Moving along then unless there's anything more we need to discuss on this?
13:38:51 <bshum> Okay
13:38:52 <bshum> #topic Evergreen releases - bug process
13:38:57 * bshum passes the mic to Dyrcona
13:39:29 <Dyrcona> I just wanted to ask if it would be OK to set Fix Releases on milestone-targeted bugs as those milestones are released?
13:40:05 <Dyrcona> What we've done for -alpha, -beta, etc. is wait for the final release, but I'd rather do it on each milestone release instead.
13:40:51 * gmcharlt prefers final releases
13:41:32 <eeevil> hrm... I'd hesitate to say a fix is released until there's a supportable version. but, if we're not using the term "release" in the strictest sense, and if it simplifies your work, I won't object.  I just think we need to be clear on what the definition of "release" is in the context of LP bugs
13:41:55 * eeevil wishes we could alter those labels...
13:42:00 <jeff> My initial thought is that the bug hasn't had a Fix Released until the final release is out. What is the argument for doing it before then? Does it make some process easier? Can we address it in another way, or are we running into a limitation in Launchpad (or how we use Launchpad)?
13:42:18 <Dyrcona> Well, I'd argue that the milestones are technically releases since the code is released in a tarball.
13:42:26 <gmcharlt> on the theory that unless folks know exactly what they're doing running pre-release code or testing it, they shouldn't be encouraged to run alphas and betas in production
13:42:41 <tsbere> If we release the "milestone" (even if it is a beta" then I would argue the fix is released. Otherwise why are we targeting at non-final releases?
13:43:24 <denials> We're targeting a fix for the next non-final release so that people can test that the fix was actually fixed when that non-final release comes out.
13:43:27 <gmcharlt> it does cry out for a status between fix committed and fix released, though "fix available for testing" or the like
13:43:31 <Dyrcona> Yeah, tsbere has rephrased it, so maybe we should change the milestones, and stop doing the -alpha, -beta, etc.
13:43:56 <jeff> Perhaps that's the better option.
13:44:08 <gmcharlt> yeah, that makes sense to me
13:44:10 <jeff> Though, does removing the pre-release milestones introduce some other issue?
13:44:12 <bshum> Well, I think having the alpha, beta, etc. lets us know how development is moving along during those milestones.
13:44:13 <Dyrcona> I'm only talking about the milestones on launchpad, not talking about not releasing tarballs.
13:44:24 <bshum> Otherwise, we couldn't track which test build contained which fixes
13:44:47 <bshum> Based on LP anyways
13:44:52 <jeff> I don't know enough about how the pre-release milestones in launchpad are used to know offhand if it would have unintended consequences to remove them.
13:44:52 <bshum> But maybe I was the only one using it that way
13:45:13 <jeff> bshum: ah, that's one case i hadn't considered. hrm.
13:45:18 <bshum> For fixes though
13:45:35 <bshum> If we setup series targets and appropriate them to the right actual milestone for the series
13:45:45 <bshum> Then the only question is how to deal with the master tracking
13:45:51 <dbwells> I have also used it the way bshum is suggesting, but could live without it.
13:45:54 <jeff> Well, using git might be the better option for determining "does this pre-release have this fix?"
13:46:04 <bshum> If it's pointed at 2.4.0-alpha, then the bug will remain open even if the 2.3 or 2.2 targets are fixed
13:46:36 <bshum> And having so many open bugs that shouldn't really be open is the thing that bothers me about not marking fix released when the master target is an alpha/beta/etc
13:48:24 <eeevil> bshum: the clutter factor is a point
13:48:30 <tsbere> It would be nice if we could say "fix committed hides it like fix released does" but we don't have that much control over launchpad.
13:48:39 * denials doesn't consider "Fix committed" as open, because he does advanced searches
13:49:03 <denials> the default summaries that Launchpad offers mean nothing to me
13:49:10 * bshum shrugs then
13:49:28 <Dyrcona> Launchpad considers Fix Committed as open, so that's an issue for people who just go there looking at how many bugs Evergreen has.
13:49:59 <denials> I guess we should ask our Marketing team how much that is deterring adoption...
13:50:00 <eeevil> so, maybe instead of redefining things like "release" we just need some canonical (haha!) searches we agree on that implement the definitions we want
13:50:27 <eeevil> denials: :)
13:50:40 <Dyrcona> We have a marketing team?
13:52:10 <berick> synergize!
13:52:34 <Dyrcona> Well, I guess the consensus is we keep doing what we've been doing.
13:52:52 <bshum> Sounds like it.  Which is fine, just raising questions.
13:53:28 <denials> maybe (pertaining to release team communication to broader world) follow up on eeevil's suggestion of canonical searches
13:53:44 <bshum> Which brings us to next topic
13:53:56 <denials> and bookmark those prominently on a dev wiki page or something (possibly on the downloads page?)
13:54:23 <bshum> #topic Evergreen releases - release cycle, team communications, etc.
13:54:51 <jamesrf> evergreen-ils.org/dokuwiki/doku.php?id=dev:bug_wrangler:faq
13:55:17 <bshum> jamesrf: That's a good page, I was going to suggest too.
13:57:30 <bshum> So, monthly release cycle.
13:58:25 <berick> clearly we need to cut an apocalypse release for Friday
13:59:26 <jamesrf> yes said release should dump the database to printed cards
13:59:39 <berick> jamesrf++
14:00:59 <bshum> There's quite a few bugs targeted to 2.3.2 and 2.2.4, but not all of them have fixes, so we can only address what we have so far.
14:01:27 <berick> given the impending holdays, i could see waiting until early Jan.
14:02:13 <denials> But on the other hand, there were a number of fixes committed since 2.3.1 - KPAC and the like
14:02:40 <denials> and waiting until early Jan. probably means waiting until late January
14:03:47 <berick> then let's cut 'em
14:04:05 <denials> IIRC some of the database upgrade scripts were also fixed up, which would impact anyone trying to get to 2.3 from a prior release
14:04:21 <bshum> Who's the 2.3 RM, senator right?
14:04:28 <berick> <--
14:04:28 <bshum> Or was that berick
14:04:32 <bshum> 2.2 is senator then
14:04:47 <berick> yeah
14:06:09 <bshum> In that case, pick a date to cut and we'll see what else we can get in under the wire I guess.
14:06:24 <bshum> For fixes I mean
14:06:29 <eeevil> like the olden days :)
14:06:32 * eeevil ducks
14:06:57 <bshum> I was using https://launchpad.net/evergreen/+milestone/2.3.2 to see what's been targeted, but have to come up with an appropriate search to narrow down to only pullrequest related ones.
14:07:04 <bshum> (it's a long list as is)
14:08:06 <bshum> I would imagine the big thing on the list is the translation string fixes from paxed that denials has been working on.
14:08:15 <eeevil> to add my bit to the "future releases" discussion, I'll be sending a provisional schedule for 2.4 alpha/beta and likely features to be merged that exist today in branches, in the near future. this week, $diety willin' and the crick don't rise
14:08:26 <berick> eeevil: to be fair, it wouldn't be like the olden days if the RM's (*me looks around at self*) were, you know, managing
14:08:35 <paxed> bshum: and there's more to come.
14:09:07 <denials> paxed++
14:09:33 <berick> so, friday 21st release sound OK?
14:09:42 * bradl hides in bomb shelter
14:10:23 <denials> berick: or heck, take what's in rel_2_3 right now rather than get panicked pushes?
14:11:00 <bshum> I'd +1 that, given what denials reminded us about KPAC fixes.
14:11:02 * Dyrcona is trying to do more automation around releases and bugs.
14:11:06 <berick> i have no objections to that, but I may have time limitations
14:11:07 <denials> Let the wire lash into the January release
14:11:08 <bshum> There were quite a few valuable pieces included.
14:11:12 <berick> could cut a pre-release branch..
14:11:23 <berick> senator: are you watching this? :)
14:11:40 <Dyrcona> +1 to just releasing what is in rather than pushing for the sake of pushing.
14:12:27 <paxed> if possible, i'd like to see bug #1078596 fixed asap :P
14:12:27 <pinesol_green> Launchpad bug 1078596 in Evergreen "Cannot translate strings handled by fieldmapper" (affected: 1, heat: 6) [Undecided,Triaged] https://launchpad.net/bugs/1078596
14:12:30 <senator> berick: aye
14:12:52 <senator> +1
14:13:16 <denials> paxed: that's next on my personal list of things to test & commit, if nobody else gets to it first
14:13:33 <berick> gotta draw a line somewhere.. tonight?
14:13:40 <berick> now?
14:13:47 <paxed> denials++
14:14:19 <bshum> How about Wednesday
14:17:02 <berick> hearing no objections.. wednesday 2pm eastern cutoff
14:17:31 * berick won't be able to cut 2.3.2 until thursday, though
14:17:44 <senator> works for me
14:18:12 <bshum> #info eeevil will be sending a provisional schedule for 2.4 alpha/beta and likely features to be merged that exist today in branches, in the near future.
14:18:44 <bshum> #info 2.3.2 and 2.2.4 to be cut this week.
14:18:49 * senator has a general sense that there will be less late merge around 2.2.x to have to accomodate anyway
14:19:29 <bshum> #link Review checklist page - http://evergreen-ils.org/dokuwiki/doku.php?id=dev:signoff_review_checklist
14:19:39 <bshum> denials++ for starting that
14:20:10 <denials> Yeah, it's a pretty random late-night /early morning dump of thoughts that I had related to an IRC discussion a couple of weeks ago...
14:20:17 <kmlussier> denials++
14:20:28 <jeff> denials++ # i said it before and i'll say it again :-)
14:20:49 <denials> Could stand to be organized better, fleshed out, etc, but I _think_ it would be useful to help people interested in signing off on stuff to remember the many different bits of QA...
14:20:56 <berick> #info berick to elect date the jan. 2.3.3 release soon
14:21:15 <denials> So please extend, enhance, improve (outwit outlast?)
14:22:14 <bshum> Cool.  Thanks denials.
14:22:23 <bshum> Anything else for discussion today as we've neared the end of the agenda?
14:22:59 * denials moves to adjourn
14:23:04 <jeff> second.
14:23:09 <denials> bshum++
14:23:10 <bshum> So moved.  Thanks everyone.
14:23:17 <bshum> #endmeeting