Salvete!
I don't recall that we did that specifically, although we did usually do custom templates for clients. We still should have some systems running simple acquisitions - however they don't work with the MARC stuff - my recollection is that once the MARC stuff came at 2.x acquisitions started to come unstuck because it had no "native" awareness of MARC. So it would work as long as you had MARC off - but not with MARC on.
I'm guessing that with later versions it got dropped as that was too hard to reconcile as most people moved to MARC.
We have some non MARC systems still running and they use simple (and possibly even some original "normal") acquisisitions.
*nod* So this would mean that it was nothing custom, it was simply an option that folks using MARC wouldn't have utilised and thought perhaps was never working. Even if it _were_ custom, and *weren't* contributed back, this is an open source project, folks are free to do that. It's nice of them to contribute things back to the main code, it's terribly helpful of them to do so, we appreciate users that chose this path the most, but if they're running it in their own Library in an altered fashion, that's their right. I'd also venture that this sort of custom experimentation is useful to the entire community in that it points to functionality that is crucial to at least one Library, which stinks to me of is possibly useful to all Libraries of that type and size. While it would be nice for someone that commits code to shepherd that commitment ad infinitum, we do still owe them thanks for submitting it in the first place. So thank you. I know my CSI professors would point out that this is why comments exist, since there is no immortal programmer. I'd much rather welcome a well commented one time contribution than not get that sort of gift since we tie a maintenance shackle to it. Finally, I'd again like to point out that out and out removal of functionality is not a bug solution. If it were bugged, then I as a user would like whatever bug (or more likely combination of bugs) it was fixed before something new was added to the core programme. If removal is the only option, I don't think it's asking to much to take a poll on this list instead of solely discussing things on the developer's list. Librarians other than me are very patient. One of my favourite things to relate in terms of new features is the 27 year bookmobile feature implementation. Yes, we're waiting for it. Yes, we've not forgot this year. Do you have it yet? No? When will you have it done? It's been a while... The pickle is in telling us something will be done by a certain date and then not meeting that, OR in promising a feature that you never deliver upon, in which case we use our Awesome Powers of Nagging. Cheers, Brooke
Finally, I'd again like to point out that out and out removal of functionality is not a bug solution.
It may not be a solution for the feature, but it is a bug solution *for that release version*.
If it were bugged, then I as a user would like whatever bug (or more likely combination of bugs) it was fixed before something new was added to the core programme.
Easily said, but practically impossible to accomplish. And surely other users would prefer to have their favorite feature integrated into a release without waiting for every outstanding bug in unrelated, orphaned features to be addressed, especially if they are paying developers to accomplish just that.
If removal is the only option, I don't think it's asking to much to take a poll on this list instead of solely discussing things on the developer's list.
A poll doesn't matter much when there isn't code to back it up. I think it would be counterproductive to conduct a poll that suggests itself as a mechanism to accomplish something when in fact it is unrelated to accomplishing it. If the group being polled had a developer they could dedicate to the task(s), or even a set number of developer hours, then it would be a totally different situation.
Librarians other than me are very patient. One of my favourite things to relate in terms of new features is the 27 year bookmobile feature implementation. Yes, we're waiting for it. Yes, we've not forgot this year. Do you have it yet? No? When will you have it done? It's been a while...
I have no idea what a 27-year bookmobile feature is, but we have sizable libraries using the existing offline circulation code for their bookmobile transactions. I suspect this would work in your case as well. I hope you don't mean that you've been waiting 27 years for an implementation! (Koha of course hasn't been around half that long.)
The pickle is in telling us something will be done by a certain date and then not meeting that, OR in promising a feature that you never deliver upon, in which case we use our Awesome Powers of Nagging.
Heh. As fearsome as those powers surely are, in my experiments, they are not impressive to the perl compiler running our Kohas. Unfortunately. I'm not sure what features/dates you are referring to, or who you think promised them. But in general, for a codebase that is moving rather quickly, I think the developer community has been reasonably pragmatic in its decisions. --Joe
Hey Brooke, My perception is that you're coming at this from the perspective of a library who's downloaded Koha on your own, and who's been active in the community with respect to documentation and help on the various mailing lists, right? ie, you haven't signed up for support with a Koha company, and you haven't contributed or sponsored any code, right? BTW: I think that's just great, hats off to you for your continued involvement and community support, it's much appreciated and the community wouldn't be the same without you and others like you. However, things get tricky because as valuable as all those activities you do are, they don't do help motivate Koha developers to change add or improve code. This isn't the kind of open source community where we've got a bunch of volunteers contributing code out of the goodness of their hearts ... over 90% of Koha is done by programmers who work on Koha as a full time job (or two) to put meals on the table. Currently, the margins on Koha development are so low, many of us have to supplement our Koha development work with other services just to make ends meet. So from that perspective, the perspective of a starving developer, what are your thoughts on how we developers can both keep our stomachs full (not to mention mortgages, etc.), and fulfill the needs of users like yourself? Some kind of voting mechanism that gives a weight of voting based on dollars, and a commitment from the development community to tap that resource for sponsoring voted-upon features? It's a very interesting problem, and I'd love to hear your thoughts on how we might solve it. Cheers, Josh On Wed, Dec 17, 2008 at 11:00 AM, Joe Atzberger <ohiocore@gmail.com> wrote:
Finally, I'd again like to point out that out and out removal of functionality is not a bug solution.
It may not be a solution for the feature, but it is a bug solution *for that release version*.
If it were bugged, then I as a user would like whatever bug (or more likely combination of bugs) it was fixed before something new was added to the core programme.
Easily said, but practically impossible to accomplish. And surely other users would prefer to have their favorite feature integrated into a release without waiting for every outstanding bug in unrelated, orphaned features to be addressed, especially if they are paying developers to accomplish just that.
If removal is the only option, I don't think it's asking to much to take a poll on this list instead of solely discussing things on the developer's list.
A poll doesn't matter much when there isn't code to back it up. I think it would be counterproductive to conduct a poll that suggests itself as a mechanism to accomplish something when in fact it is unrelated to accomplishing it. If the group being polled had a developer they could dedicate to the task(s), or even a set number of developer hours, then it would be a totally different situation.
Librarians other than me are very patient. One of my favourite things to relate in terms of new features is the 27 year bookmobile feature implementation. Yes, we're waiting for it. Yes, we've not forgot this year. Do you have it yet? No? When will you have it done? It's been a while...
I have no idea what a 27-year bookmobile feature is, but we have sizable libraries using the existing offline circulation code for their bookmobile transactions. I suspect this would work in your case as well. I hope you don't mean that you've been waiting 27 years for an implementation! (Koha of course hasn't been around half that long.)
The pickle is in telling us something will be done by a certain date and then not meeting that, OR in promising a feature that you never deliver upon, in which case we use our Awesome Powers of Nagging.
Heh. As fearsome as those powers surely are, in my experiments, they are not impressive to the perl compiler running our Kohas. Unfortunately.
I'm not sure what features/dates you are referring to, or who you think promised them. But in general, for a codebase that is moving rather quickly, I think the developer community has been reasonably pragmatic in its decisions.
--Joe
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
participants (3)
-
BWS Johnson -
Joe Atzberger -
Joshua Ferraro