<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>Finally, I'd again like to point out that out and out removal of functionality is not a bug solution. </div>
</blockquote><div><br>It may not be a solution for the feature, but it is a bug solution *for that release version*. <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>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. </div></blockquote><div><br>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. <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>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. </div>
</blockquote><div><br>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. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>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... </div>
</blockquote><div><br>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.)<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>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.</div>
</blockquote><div> <br>Heh. As fearsome as those powers surely are, in my experiments, they are not impressive to the perl compiler running our Kohas. Unfortunately. <br><br>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. <br>
<br>--Joe<br><br></div></div>