On Thu, Feb 28, 2013 at 10:56 AM, Jason Stephenson <[email protected]>wrote:
> Quoting "Elfstrand, Stephen F" <[email protected]>: > > there are a lot of direct calls to the database from the client, >> > > Speaking as one of the developers, I have to correct the above statement. > No such thing happens in Evergreen. The client cannot talk directly to the > database, it goes through OpenSRF which handles database communication on > the backend. > > And speaking as another of the developers, I'd love to see evidence of problems (really -- we can't address issues without it). New features and their supporting code and database structures certainly introduce new opportunities for optimization (database indexes, condensed APIs, etc), but these opportunities are often not visible until real-world load is applied, and in the words of a great man, "premature optimization is the root of all evil" (http://c2.com/cgi/wiki?PrematureOptimization). If you have such evidence, please share. I, for one, have a nice pile of evidence and addressing changes that are becoming a working branch right now. As for assigning the job of QA to the release manager, assuming the community wants a 6-month release cycle and admitting that the RM role is a single volunteer position with no real power except to say "no" to a release, I don't think that is reasonable as the structure exists today. In the larger sense, I believe we're driving at the same point, of course -- the lack of QA, particularly performance QA, before a release. There is a chicken-and-egg problem here, however, and what we really need, as a community, is an ongoing effort -- certainly supported by and augmented with specific tactical audits of all the things you point out, and more -- that is separate from the release process itself (though informing it, obviously) to make sure that the currently desired round of analysis and repair is not the last. It's that ongoing effort, and the human and technical infrastructure that must, somehow, be sustained that I think is a bigger problem than any individual performance regression. Equinox is making the attempt at creating that. We've been getting good, positive feedback, and our efforts are intentionally orthogonal to, and /not/ mutually exclusive with, all other the discussions currently ongoing. We're working hard to make sure that stays true, and that what we end up doing with and for the rest of the community is part of a larger whole. We don't want to waste anyone's time, so we're making sure we get things as right as possible out of the gate, but we'll be sharing more information soon. However, and I can not stress this enough, this should not cause anyone to stop their own efforts! We all benefit from as much participation as possible by all types of community members: service providers, libraries and those institutions that straddle the line between both. -- Mike Rylander | Director of Research and Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: [email protected] | web: http://www.esilibrary.com
