13:07:33 <bshum> #startmeeting 2012-11-15 - Developer Meeting
13:07:33 <pinesol_green> Meeting started Thu Nov 15 13:07:33 2012 US/Eastern.  The chair is bshum. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:07:33 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:07:37 <bshum> Thanks kmlussier++
13:07:50 <bshum> #topic Who's here.
13:08:00 <bshum> #info bshum = Ben Shum, Bibliomation
13:08:04 <denials> #info denials is Dan Scott, Laurentian University
13:08:19 <Dyrcona> #info Dyrcona is Jason Stephenson, MVLC
13:08:23 <tsbere> #info tsbere is Thomas Berezansky, MVLC
13:08:27 <kivilahtio> #info kivilahtio = Olli-Antti Kivilahti, Regional Library of Joensuu
13:08:37 <jeff> #info jeff is Jeff Godin, Traverse Area District Library (TADL)
13:08:42 <jdouma> #info jdouma is Justin Douma, Catalyst IT
13:08:42 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC
13:08:53 <davidcboyle> #info davidcboyle is  David Boyle, Catalyst IT Services
13:08:58 <jBond> #info jBond Jeffrey Bond, Catalyst IT
13:09:00 <ktomita__> #info ktomita is Kyle Tomita, Catalyst IT
13:09:11 <moodaepo> #info moodaepo = Anoop Atre, Equinox
13:09:27 <acoomes> #info acoomes is Andrew Coomes, Catalyst IT Services
13:09:30 <smyers_> #info smyers_ is Scott Myers, Catalyst It Services
13:09:45 <b_bonner> #info b_bonner = Bradley Bonner, King County Library System
13:09:54 <bshum> #link Meeting agenda: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2012-11-15
13:09:56 <denials> lots of new names, yay! and welcome :)
13:10:29 <bshum> I just copied the next doc to the actual notes page for now.  I'll fill the gaps post-meeting.
13:10:59 <dbwells> #info dbwells is Dan Wells, Hekman Library
13:11:19 <bshum> Okay, as other folks come in, feel free to note your presence.  But let's get rolling with the agenda, lots to cover today.
13:11:29 <bshum> #topic Previous action items
13:11:33 <paxed> #info paxed = Pasi Kallinen, Regional Library of Joensuu
13:11:44 <bshum> #info All past action items appear to be done.
13:11:52 <bshum> Huzzah!
13:11:55 <remingtron> #info remingtron = Remington Steed, Hekman Library
13:12:05 <kivilahtio> Huzzah!
13:12:11 <bshum> #topic Security release process post-mortem
13:12:23 <bshum> Turning it over to denials and his shaky connection to discuss.
13:13:05 <denials> Well, the bulk of my thoughts (such as they are) are in the agenda
13:13:15 <denials> Basically, we can't kee going on like this.
13:13:21 <kivilahtio> well well
13:13:40 <Kabi> im working on hacking this app togeter now
13:13:40 <kivilahtio> I have been asking the dev mailing list about some help with planning our security review of evergreen
13:13:53 <kivilahtio> we already have funding for a pretty extensive security review for Evergreen
13:14:01 <denials> bug 1079303 is an example of the problem that comes with a lack of testing
13:14:01 <pinesol_green> Launchpad bug 1079303 in OpenSRF "Log Redaction code can lead to crashes in OpenSRF clients." (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1079303
13:14:03 <jeff> agreed. can the existing buildbot infrastructure be expanded and utilized for testing all releases, both security and non?
13:14:05 <denials> kivilahtio: different problem
13:14:15 <kivilahtio> but we lack a functional production environment and the expertise to guide this 3rd party in their investigation
13:14:22 <denials> jeff: sure. but the buildbot can only test automated tests
13:14:22 <kivilahtio> daaaaamn!
13:14:36 <Kabi> you saying version 14 or above
13:14:43 <jeff> denials: right. leads into my next question...
13:14:52 <denials> a security buildbot would have to be privatized too.
13:15:01 <jeff> figured, yes.
13:15:07 <denials> Kabi: we're in the middle of a dev meeting; can you hold your question for a half hour or so?
13:15:35 <jeff> so, can we start with a group of folk tasked with testing more than what buildbot tests, and then i think automated testing is a topic further down the agenda?
13:15:59 <denials> and the buildbot typically doesn't go through the "install opensrf and evergreen on a basic server and set up a full regression environment"
13:16:17 <jeff> because as you stated, it should not and cannot fall entirely on the shoulders of the release manager/maintainers.
13:16:31 <denials> which would do a better job of covering off the "does aptitude exist here anymore?" issues :)
13:17:00 <denials> we covered a lot of discussion on these fronts during the hack-a-way too :/
13:17:06 <jeff> yes, and things like package renames, etc, etc. all those lovely Makefile.install external dependencies that are subject to distro breakage.
13:17:08 <Dyrcona> i've got building from a vm straight through Evergreen installation mostly automated on my end. I could share those scripts.
13:17:12 <tsbere> One thing might be to ask for volunteers to join the security list/team, vetted by the existing members. That would also give us more people able to test possible security issues. System admins from known systems would be a decent start, I think.
13:17:36 <denials> Or we could throw out the whole closed security process
13:18:10 <berick> not sure if denials is joking, but I kind of agree
13:18:20 <berick> seems to cause as many problems as it solves
13:18:23 <denials> But we would still benefit from more automated testing, in any case.
13:18:35 <kivilahtio> denials: ++
13:19:16 <kivilahtio> the people from Netherlands don't really appreciate this lack of regression testing
13:19:22 <kivilahtio> and that goes for me
13:19:23 <bshum> #info Benefits to be gained from setting up a more thorough automated testing process for releases (security or otherwise)
13:19:24 <kivilahtio> too
13:20:43 <bshum> Are there significant drawbacks to opening the security process so that there is more involvement (and testing) by other community members outside the development team?
13:20:46 <denials> kivilahtio: well, the people from the Netherlands are more than welcome to contribute regression tests.
13:21:19 <kivilahtio> denials: how should we approach doing them? I understood there has been some thought already about a testing framework in Evergreen
13:21:19 <denials> (I'm serious, we have a limited pool of dev resources and could use some of their skills)
13:21:22 <edoceo> Like Dyrcona I too have scripts that scratch-build evergreen - perhaps we should both post those to the Wiki - and I can allocate a machine for folks to security test (or other test) against
13:21:32 <Dyrcona> bshum: someone could exploit existing Evergreen installations with the information. What they would gain by doing so is another question.
13:21:53 <csharp> significant drawback: if the security process is open, orgs like us who run releases forever are vulnerable
13:21:55 <denials> bshum: the significant drawback is "we know that passwords are getting exposed via hole X, but we don't have a solution yet"
13:21:55 <paxed> edoceo & Dyrcona: please do; I started writing such script myself already, but didn't finish...
13:21:59 <kivilahtio> denials: I am already thinking on how to incorporate regression testing in the developments we are about to undertake
13:22:08 <denials> until there's a solution, hole X is wide open for anyone to exploit.
13:22:35 <berick> denials: perhaps we open it up after there is a solution, but before we've done all of the release cutting and testing..
13:22:39 <berick> that was the hard part
13:22:39 * denials looks forward to #action items :)
13:22:40 <bshum> What if when we have solutions (even if just being patches for testing) we pass this along to the community for some review.
13:22:51 <bshum> Or you know, what berick said :)
13:23:07 <denials> berick: true true
13:23:51 <jeff> automated build process is one part, more unit tests (or in some subsystems, ANY unit tests) is another. how can interested parties put our heads together on this? it doesn't strike me as something that will be solved during this meeting, and it doesn't make sense for everyone to be duplicating effort.
13:23:52 <csharp> maybe there could be 2 levels of "closed" 1) the "inner circle" of devs who know the details and 2) a vetted list of admins who need to know the results of the inner circle's work
13:24:19 <tsbere> I also still think that allowing more trusted sysadmin-type people into the "closed" part of the process is a good idea. (Or, in csharp's 2 level, the "inner circle")
13:24:39 <tsbere> Having sysadmins could give us access to information on how much impact things might have if they are configuration dependent
13:24:57 <tsbere> Things that we otherwise might not be able to ask without revealing why we are asking anyway
13:25:30 <denials> mmm. I'm worried about too much complexity
13:25:49 * tsbere feels that multiple closed levels won't do a lot of good, just let the vetted admins into the whole thing
13:26:07 <edoceo> +1 ^^
13:26:08 * csharp was just running that up the flagpole
13:26:19 <senator> i would personally favor full disclosure over a system like that. no admins get left in the dark that way, at least
13:26:24 * denials worries excluding people is fairly negative
13:26:26 <jeff> denials: you mentioned that buildbot does not start with a fresh install. can it be configured to do so, or are we looking at using some other tool (vagrant, which I and I think jamesrf have played with, etc)?
13:26:29 <denials> senator++
13:26:44 <denials> jeff: that's not really what buildbot is meant for
13:26:48 <jeff> noted.
13:27:03 <Dyrcona> i'm inclined toward full disclosure, too, despite the drawbacks.
13:27:06 <denials> vagrant, boxgrinder, yada yada - back to GSoC 2011
13:27:40 <csharp> well, Debian's security list goes into details, but that's after a fix is available
13:28:03 <denials> yeah. the dev team has a pretty broad set of representation at this point
13:28:15 <csharp> (which was kinda the idea behind the 2-level approach)
13:28:21 <denials> if we find a hole, come up with a fix that seems to work across those environments, then disclose?
13:28:38 <denials> (which was berick's proposal)
13:28:42 <jeff> we've identified a need for tools to make the release (any release) process run smoother, inflict less stress on a small number of already stressed developers, etc. how far do we want to take this during this agenda item? was there any kind of action item proposed at the hack-a-way in regard to testing efforts?
13:28:43 <csharp> right
13:28:43 <bshum> I'd +1
13:28:44 <senator> +1
13:28:52 <bshum> So...
13:29:17 <csharp> but the "we" that finds the hole - is that the existing security team?
13:29:19 <denials> jeff: there was "Continuing hack-a-way efforts towards more testable code" on the agenda
13:29:43 <denials> csharp: that could be anyone - using the existing security mailing list / security bug
13:29:45 <senator> well anyone can find the hole, but ideally they'd report to the existing security team, then as soon as a solution is available, boom. that's what we're saying anyway, right?
13:29:46 <bshum> csharp: I think that if someone were to submit a security bug ticket, it would still give them the ability to view the discussions.
13:29:54 <denials> it does
13:29:54 <jeff> senator: yes.
13:29:57 <csharp> okay gotcha
13:30:03 <eeevil> jeff: http://nox.esilibrary.com/~miker/hackaway-testing-whiteboard-2.jpg
13:30:08 <jeff> eeevil: thanks
13:31:13 <dbwells> I would also like to add that, assuming there is still a security team, we could still choose to announce the fix only or package a new version on a case-by-case basis.
13:31:28 <dbwells> depending on severity.
13:31:43 <eeevil> http://nox.esilibrary.com/~miker/hackaway-testing-whiteboard-1.jpg
13:31:53 <tsbere> I agree with dbwells
13:32:34 * csharp visited a library just yesterday to observe "real-life" use of EG and will visit another on 11/29
13:32:49 <tsbere> I don't think we needed to worry too much about the "log files store stuff" given that most people with access to the logs can do a lot more, for example.
13:33:38 <tsbere> Fixing it is good. Freaking out about it not as much.
13:34:04 <bshum> #info Disclose information pertaining to security-related bugs once a fix is available. This allows for testing (and fixing) to be conducted by community members outside the core team members.
13:34:37 <kivilahtio> +1
13:34:38 <bshum> And we can discuss final details to that later in list and make an announcement I guess.
13:34:52 <denials> tsbere: please don't assume that your environment matches every other environment. Please.
13:35:07 <jeff> if we're seeking action items, i suggest the following two: $someone volunteers to draft a write-up of the current "how we handle security-related bugs", we fold 'tests make releases better' into the later agenda item, and we continue the current security process (only smoother, with testing!) as laid out in the doc.
13:35:30 <jeff> and bshum beat me to a summary.
13:35:56 <denials> csharp++
13:36:15 <b_bonner> I also +1 bshums suggestion that the person who submits security related bug can see the discussion.
13:36:32 <denials> b_bonner: that's already the case
13:36:38 <bshum> #action Draft summary of "how we handle security-related bugs" and disseminate through appropriate channels.
13:36:45 <denials> (at least for security bugs)
13:36:46 <jeff> b_bonner: and that is current practice. "security" bugs on launchpad are visible to the submitter and the security team.
13:37:09 <edoceo> Dyrcona: can you add your script information at http://open-ils.org/dokuwiki/doku.php?id=dev:start ?
13:37:11 <jeff> (and it'll be documented as such after that action item there is done! ;-)
13:37:16 <denials> We haven't had a hole submitted to the mailing list by a non-dev member for...ever
13:37:23 <b_bonner> ok, sorry. My example was submitted by a third party. nvm
13:37:59 <berick> is it possible to add people to a security bug?
13:38:19 <dbwells> that's a good question
13:38:30 * tsbere has never tried to add anyone to a bug other than himself
13:39:00 <jeff> berick: i believe so. i think it would be useful to confirm that, and add some bits to the document noting that others may be added as needed (and what "needed" means -- mostly i see that being useful in adding co-workers / support vendor + customer, etc)
13:39:05 <dbwells> There is the "Subscribe someone else" link
13:39:20 <dbwells> I'm going to try, just a second.
13:40:56 <dbwells> sorry, the bugs I have open aren't security bugs anymore apparently
13:41:07 <bshum> I have one I can test after the meeting.
13:41:21 <denials> who is the action person or people assigned to "Draft summary"?
13:41:28 <jeff> I'll grab the "draft summary" action item.
13:41:33 <denials> jeff++
13:41:36 <bshum> jeff++
13:41:39 <Dyrcona> jeff++
13:41:51 <jeff> Do we have anything else for this agenda item at this time?
13:42:50 <jeff> bshum: next? :-)
13:42:51 <bshum> If not then we can move on for now
13:43:01 <bshum> Okay
13:43:03 <bshum> New topic
13:43:09 <bshum> #topic Ancient version of Dojo
13:44:27 <bshum> I vaguely recall tsbere talking about this during the hackaway
13:44:29 <berick> tsbere: IIRC, there is a branch that gets EG up to 1.6, correct?
13:44:46 <tsbere> I don't recall finding any major issues with up to 1.6
13:44:49 <berick> it just needs a pile of testing
13:44:52 <tsbere> 1.7+ is problematic
13:45:15 <Dyrcona> tsbere: That's Joe Lewis' branch?
13:45:27 <bshum> http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/dojo_1.6_maybe
13:45:27 <tsbere> Minus a couple of commits
13:45:33 <berick> getting to 1.6 by 2.4 would be nice, if possible
13:46:19 <kmlussier> Could somebody set up a Dojo 1.6 testing server like tsbere did for newxul?
13:46:55 <edoceo> I'll give that a go
13:47:27 <csharp> edoceo++
13:47:27 * kmlussier would be wiling to test and put out a call for other end-user testers.
13:47:44 <csharp> kmlussier+++
13:47:47 <csharp> er..
13:47:47 <denials> My secondary concern is that jlewis put in a ton of work and not much has happened with it yet, which is probably not optimal for making him feel like a valued contributor :/
13:47:50 <csharp> kmlussier++
13:48:15 <denials> but happy to see things moving now at least. edoceo++ kmlussier++
13:48:37 <bshum> #action edoceo to work on setting up a dojo 1.6 test server
13:48:38 <edoceo> My git-fu is a little weak, so I'll get a system running master then I can come back in here and ask for some git-commands to get that branch running
13:48:48 <dbwells> not to derail the current topic, but I've confirmed that you can add outsiders to a security bug.  Carry on...
13:48:57 <bshum> #action kmlussier to help coordinate end-user testing
13:49:15 <denials> edoceo: we have git-fu to spare in channel, and will have you devoted to it in no time :)
13:49:37 <edoceo> iptables-save
13:49:39 <edoceo> oops
13:49:55 <bshum> Heh, anything else about dojo for the moment?
13:50:04 <tsbere> Well
13:50:18 <tsbere> I would, honestly, like to get rid of it as much as possible >_>
13:50:22 <bshum> dbwells: Thanks for checking on that.
13:50:38 <Dyrcona> yeah, why not just get rid of dojo?
13:51:01 <berick> can we have that talk at the EG conference instead? :)
13:51:04 <tsbere> I have no problem with replacing most to all of the dojo interfaces with xul interfaces, or pure TT interfaces as appropriate.
13:51:12 <berick> or during not-dev-meeting
13:51:17 <Dyrcona> Sure.
13:51:20 <tsbere> berick: I won't be at the conference. So I would prefer it not be there ;) Not-dev-meeting is ok.
13:51:29 <bshum> Heh, agreed, we can discuss proposals for that in further length on lists or out of this meeting.
13:51:31 <denials> or dedicated dev metting
13:51:35 <berick> tsbere: well, dang.  irc it is
13:51:40 <tsbere> but hey, bshum asked for anything else about dojo. ;)
13:51:51 <bshum> I know, I already kicked myself for being too vague :)
13:52:02 <bshum> Okay, if nothing else, moving to next topic for now
13:52:15 <bshum> #topic Only support server editions
13:52:21 <denials> we're going to need some javascript framework somewhere for little things like autocomplete and whatnot... but yeah, next topic
13:52:48 <bshum> This came out of issues relating to Ubuntu's various versions and quirks, but extends to all supported Linux distros I think.
13:52:59 <edoceo> Well, not Gentoo
13:53:16 <csharp> of course Debian is just Debian too, so there are a few exceptions
13:53:19 <bshum> If that's the direction we want to go, I'll take an action item to update various website pages to reflect some of that.
13:53:33 <denials> Can we state specific distros that we support?
13:53:39 <bshum> By all supported I just mean that we should make a specific list
13:53:40 <eeevil> +1
13:53:44 <Dyrcona> denials: I say yes we can.
13:53:47 <csharp> denials: +1
13:53:51 <dbwells> +1
13:54:13 <tsbere> I would be willing to go so far as to state that we only test specific 32/64 bit variants of the distros
13:54:18 * denials is an example of a passionate community member who will maintain + improve Fedora support, but doesn't expect the rest of the community to carry any of that load
13:54:24 <csharp> and add something like "don't see your favorite here?  here's how to get involved: <link>"
13:54:59 <denials> csharp++
13:55:07 <edoceo> I'll do like denials but for Gentoo - only 64bits, 32bits is as dead as Dojo 1.3 :D
13:55:07 <paxed> and automated install scripts will help testing different distros.
13:55:07 <Dyrcona> csharp: +1
13:55:18 * berick will add his name to the Debian maintainers
13:55:19 <jlamos> I'd be curious to know about issues that only crop up in "desktop" variants of distros
13:55:57 * dbwells can pitch in with 64-bit Ubuntu Server LTS releases
13:56:14 <Dyrcona> jlamos: Desktop Ubuntu 12.04 doesn't install some things that the server install does, for example.
13:56:21 <jeff> jlamos: there may be none -- in which case, hooray! the idea would be to state which versions are explicitly tested and supported.
13:56:27 <denials> and conversely, desktop distros tend to come with more base packages
13:56:30 * tsbere can help with ubuntu 64 bit
13:56:44 <denials> like X and Firefox / xulrunner :)
13:56:53 * csharp can assist (to some extent) with Debian and Ubuntu LTS
13:57:02 * denials is a Debian-ista as well
13:57:39 <denials> #info denials will support Fedora and Debian
13:58:11 <berick> #info berick will support Debian
13:58:31 <Dyrcona> #info Dyrcona will support Ubuntu
13:58:50 <tsbere> #info tsbere will support Ubuntu
13:58:51 <edoceo> #info edoceo will support Gentoo
13:59:06 <dbwells> #info dbwells will support Ubuntu
13:59:08 <eeevil> #info eeevil will support Debian
13:59:18 <bshum> #info bshum will support Ubuntu
13:59:35 <csharp> #info csharp will support Ubuntu and Debian
14:00:32 <denials> Next topic time?
14:00:34 <bshum> Alright, well it's 2 pm, but we still have tons on the agenda.
14:00:39 <denials> zactly
14:00:45 <bshum> Let's see what we can whip through I guess.
14:00:51 <paxed> pfft, it's 9pm
14:00:55 <bshum> #topic Search infrastructure progress
14:01:55 <bshum> Who are the people working on this area?
14:02:00 <denials> eeevil / tsbere : is there a bug associated with the queryparser / driver bug fixes?
14:02:02 <eeevil> #info eeevil might support Slackware
14:02:11 <denials> eeevil++
14:02:16 <csharp> eeevil++
14:02:27 <tsbere> denials: I have one, but it doesn't quite cover everything that has happened
14:02:34 <eeevil> whoa... laggy here. sorry
14:02:37 * csharp will not support LFS
14:02:41 <dbwells> I think we need to prioritize the rest of the agenda, these are some big topics, and I don't think we can cover them all today without losing some people (myself included)
14:03:05 * denials eyes the 20% power left on his lappie
14:03:34 * denials guesses the "ripping out JSPAC" might be a priority?
14:03:55 <bshum> Sounds reasonable to me.
14:04:07 <denials> (as much as I want to backport fixes for the search errors that are filling our logs, we can hopefully handle that outside of meeting)
14:04:26 <bshum> #info Deferred, with need to expand on bug tickets associated with queryparser / driver bug fixes
14:04:30 <eeevil> I'm in favor of pushing tsbere's extension of my extension of jcamins' branch
14:04:35 <eeevil> to master
14:04:47 <tsbere> eeevil: The main issue, I think, is the tests that currently fail. I haven't had a chance to look though.
14:04:49 <eeevil> gah ... again, lag, sorry
14:05:09 <eeevil> tsbere: me either ... I'll continue looking for time
14:05:25 <denials> So everyone's cool with ripping out JSPAC?
14:05:41 <bshum> #topic Ripping out JSPAC
14:05:41 <berick> denials: are we just talking the xml at this point?
14:06:02 <berick> hm, incomplete question.  nevermind
14:06:04 <jeff> no objections, and +1 to the idea of picking a tag to stick on bugs. blocks_jspac_removal?
14:06:49 <tsbere> I don't object to jspac removal, and I don't object to removing it *without implementing all the features*, for that matter.
14:07:13 <alexlazar> it would be helpful to have a list of features that will be lost with JSPAC removal
14:07:17 <eeevil> denials: I'd rather see feature parity, but won't actively work against consensus to the contrary
14:07:37 <tsbere> A list of features yes, requiring that the list of "missing" features be empty though I don't see as a priority.
14:07:44 <denials> Is there anyone who cares enough about feature parity to create such a list?
14:07:53 <kmlussier> I don't think it's realistic to wait until all the features are implemented, but I'll go through bugs and tag them.
14:08:07 <csharp> I care, but I don't know enough about what's not in TPAC yet
14:08:15 <denials> kmlussier: there might be a number of bugs to create, too
14:08:17 <kmlussier> I thought we already had a list of features.
14:08:21 * csharp looks around for mrpeters-isl
14:08:53 <bshum> In the agenda, there was a mention of this wiki page: http://www.evergreen-ils.org/dokuwiki/doku.php?id=dev:opac:template-toolkit:plan
14:09:04 <denials> kmlussier: per the agenda, that list (at least the page I found) is a mix of new wishlist items, missing features, and out-of-dateness
14:09:08 <jeff> i suggest that someone volunteer to edit the existing wiki page on the subject, create bugs where there are features still missing, and edit the wiki page to reference the list of bugs (link to a search by tag, etc)?
14:09:10 <bshum> Which does have some information, but isn't specifically constructed with the goal of deciding what we need to do left.
14:09:37 * kmlussier volunteers
14:09:41 <jeff> kmlussier++
14:09:42 <bshum> kmlussier++
14:09:46 <kmlussier> But I'm happy to work with others too.
14:09:50 * kmlussier nudges bshum
14:10:04 <bshum> Yeah, I'll help, since I actually used that page as my pro/con to switching up to TPAC when our time came too.
14:10:29 <kivilahtio> I think we already have such a list
14:10:35 <bshum> #action kmlussier, bshum (and others) to edit the TPAC plan wiki page and create appropriate bug links if necessary.
14:10:43 <csharp> kmlussier: I'll be willing to help too once I have a test instance running
14:10:53 <denials> and in some cases, such as "spell check", JSPAC's implementation kind of sucks ...
14:11:03 <kmlussier> csharp++
14:11:13 <bshum> #help People with concerns about specific features missing from TPAC should contribute and note specific blockers to ripping out JSPAC.
14:11:59 * csharp thinks we should put "missing" in quotation marks and think of those as "features you'd like to see again"
14:12:09 <kivilahtio> :)
14:12:09 <eeevil> my wiki pw is ... currently unknown. but "Depth-based org hiding" is done now, fwiw (under sponsered features)
14:12:12 <bshum> csharp: +1
14:12:33 <denials> +1 to jeff's suggestion for "blocks_jspac_renewal" tag
14:12:33 <csharp> the way we talk about that matters, especially in my organization
14:12:59 <alexlazar> csharp: good idea
14:13:18 <kivilahtio> so wwhere do we collect the missing items?
14:13:30 <mrpeters-isl> i'm here...sorry csharp
14:13:30 <kivilahtio> who will create the wiki page?
14:13:39 <mrpeters-isl> just got back....what did you need me to chime in on?
14:13:55 <denials> kivilahtio: can you just revamp http://www.evergreen-ils.org/dokuwiki/doku.php?id=dev:opac:template-toolkit:plan ?
14:14:07 <csharp> mrpeters-isl: we're just talking about JSPAC features we'd like to see in TPAC
14:14:09 <jeff> mrpeters-isl: you can help kmlussier and bshum tend bugs for things that could block removal of jspac (things that jspac does that people would miss)
14:14:11 <alexlazar> denials: +1
14:14:37 <mrpeters-isl> sure i can
14:14:51 <mrpeters-isl> that page we discussed last time had a decent list
14:14:59 <mrpeters-isl> i'll get with kmlussier and bshum on it
14:15:02 <bshum> Cool :)
14:15:15 <jeff> mrpeters-isl: see discussion above whenever you have time.
14:15:18 <bshum> Okay, so moving in the direction of saying goodbye to JSPAC
14:15:22 <berick> regardless of missing features, are we agreed jspac can dissappear in 2.4?
14:15:29 <mrpeters-isl> id +1 that
14:15:32 <csharp> berick: I think so
14:15:48 <berick> groovy
14:15:54 <bshum> #agreed JSPAC can disappear in 2.4.
14:16:01 <denials> prep that branch!
14:16:05 <csharp> it won't work with the default browsers of the mainly-used OSs so no one will miss it
14:16:21 <mrpeters-isl> nobody has complained here
14:16:23 <kivilahtio> +1
14:16:23 <mrpeters-isl> we ripped it out already
14:16:28 <denials> as did we
14:16:33 <bshum> The last thing I'd like to talk about today, if only for a moment is the bug backlog issue.
14:16:37 <mrpeters-isl> just a few features people miss,but not many at all
14:16:45 <bshum> #topic Bug backlog
14:17:01 <mrpeters-isl> bshum: i did a little wrangling yesterday but i saw LOTS of "New" unconfirmed bugs
14:17:14 <denials> it's only 504 open bugs
14:17:17 <mrpeters-isl> i can dedicate some more time to testing/confirming the ones i understand
14:17:28 <jeff> suggest action item: those who can, test. those who can, pull. those who can, confirm/flesh-out.
14:17:37 <bshum> denials: Already better than where we were a few months (or wait, years?) ago.
14:17:44 <mrpeters-isl> i do that, at least once a week
14:17:53 <bshum> jeff++ :)
14:18:05 <jeff> i have some sip-related things to focus on which i think i can pull some of Dyrcona's branches and pester him or others to look at some of mine.
14:18:09 * denials notes that it's a hell of a lot easier to pull if there are tests
14:18:25 <jeff> denials: yes, but i think we skipped that agenda item. ;-)
14:19:32 <jeff> append: those who can, add tests for your pullrequests. do we want to start on a case-by-case basis using a testsrequested tag and throwing it back to the author of the working branch?
14:19:55 <csharp> those who can't teach - those who can't teach teach gym
14:20:14 <denials> is there a need for a quick Test::More test creation howto?
14:20:16 <jeff> or just commenting that a pull isn't likely without tests? does anyone want to create some tests for some bugs (their own or others) and point at them as good examples?
14:20:28 <jeff> denials: i would be interested.
14:20:30 * denials might be able to sign up for that, but has 5% lappie power and is shutting down
14:20:34 <eeevil> related, are we opening up the github floodgates, or should we push for our-repo branches? (yes, almost entirely new stuff on github, but precedent being what it is...)
14:20:34 <Dyrcona> denials: +1
14:20:41 <tsbere> denials: howtos are good.
14:20:42 <jeff> denials: thanks! adios!
14:20:57 <kivilahtio> denials: I'll talk with the royal dutch academeers and try to come op with somekind of a testing framework, atleast when we start doing dev work next january we will try to use regression testing
14:21:01 <tsbere> I vote against github pulls
14:21:24 <mrpeters-isl> it is nice having everything in working
14:21:31 <mrpeters-isl> i dont even know how to pull from github to test something
14:21:34 <tsbere> In part because we aren't using github as a community, we put it there more to be nice to those who prefer poking via it.
14:21:42 <mrpeters-isl> so i personally would ignore them
14:21:45 * tsbere knows how to pull from github, though
14:21:56 <mrpeters-isl> i know i could learn :)
14:22:09 <tsbere> At the very least github-based branches should be submitted to us via launchpad with pullrequest tags, not via github pull requests.
14:23:03 <Dyrcona> I agree with no pulls from anywhere without a Launchpad entry.
14:23:40 <denials> And they need to have signed-off.
14:24:05 <bshum> #info Jeff's summary: "those who can, test. those who can, pull. those who can, confirm/flesh-out."
14:24:36 <tsbere> Oh, definitely on the signed-off. I am willing to add people's github repos for testing, but they still need to follow our submission guidelines for sign-offs and such.
14:24:49 <bshum> #info Examples of test creation would be helpful to new coders.
14:25:20 <paxed> bshum++
14:26:03 <bshum> #info Contributors via github should still follow the guidelines set by the community for submissions (including sign-offs, launchpad entry, etc.). Preference towards using the community working repo.
14:26:08 <bshum> Just summarizing for the notes.
14:26:38 <dbwells> bshum: perfect summary
14:26:43 <ktomita> bshum++
14:26:57 <bshum> Okay, I think that's all I can do for now, but I'd like to thank everyone for coming to this meeting and contributing to the discussion.  I'll go through the notes in a bit and get things moved to the next meeting's agenda for stuff we haven't covered today.
14:27:06 <denials> bshum++
14:27:09 <berick> bshum++
14:27:11 <bshum> As always, we can carry on the discussion in IRC, lists, etc.
14:27:15 <acoomes> bshum++
14:27:31 <bshum> Thanks to kmlussier for setting up the doodle poll to determine meeting times.
14:27:34 <dbwells> bshum++
14:27:39 <jeff> bshum++
14:27:42 <jBond> bshum++
14:27:42 <jeff> thanks, all!
14:27:49 <kmlussier> bshum++
14:27:49 <bshum> #endmeeting