<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 29, 2018 at 12:58 PM, David Kastrup <span dir="ltr"><<a href="mailto:dak@gnu.org" target="_blank">dak@gnu.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Paul Davis <<a href="mailto:paul@linuxaudiosystems.com">paul@linuxaudiosystems.com</a>> writes:<br>
<br>
> we have found bugs in libsmf that we have not pushed upstream for<br>
> various reasonably defensible reasons.<br>
<br>
</span>Without wanting to dwell on it and just out of personal curiosity (sort<br>
of having been on either side): what class of reasons would that be?<br></blockquote><div><br><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">libsmf has been written with a clear tendency toward "if the SMF is not perfect, we cannot load it". Ardour wants a somewhat more tolerant behaviour, so quite a few of our changes have involved making that the case.<br><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">on top of that, we wanted to treat libsmf as a genuinely internal library that so if we wanted to amend it in more fundamental ways, we wouldn't need to stop and think about that for even a second. the first thing that we ever did with it, back in 2009, was to strip the code down to suit that purpose.<br><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">we probably could have/should have tried to push a few of our fixes in the direction of libsmf's current maintainer. that's my fault, but also a function of time overload.<br></div><br></div></div></div></div>