<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&#39;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*.&nbsp;  <br>&nbsp;</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.&nbsp; 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.&nbsp; <br>
&nbsp;<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&#39;t think it&#39;s asking to much to take a poll on this list instead of solely discussing things on the developer&#39;s list. </div>
</blockquote><div><br>A poll doesn&#39;t matter much when there isn&#39;t code to back it up.&nbsp; 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.&nbsp; 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.&nbsp; <br>
&nbsp;</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&#39;re waiting for it. Yes, we&#39;ve not forgot this year. Do you have it yet? No? When will you have it done? It&#39;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.&nbsp; I suspect this would work in your case as well.&nbsp; I hope you don&#39;t mean that you&#39;ve been waiting 27 years for an implementation!&nbsp; (Koha of course hasn&#39;t been around half that long.)<br>
&nbsp;</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>&nbsp;<br>Heh.&nbsp; As fearsome as those powers surely are, in my experiments, they are not impressive to the perl compiler running our Kohas.&nbsp; Unfortunately.&nbsp; <br><br>I&#39;m not sure what features/dates you are referring to, or who you think promised them.&nbsp; But in general, for a codebase that is moving rather quickly, I think the developer community has been reasonably pragmatic in its decisions.&nbsp; <br>
<br>--Joe<br><br></div></div>