<br><br><div class="gmail_quote">2009/10/23 Michel Alexandre Salim <span dir="ltr">&lt;<a href="mailto:michael.silvanus@gmail.com">michael.silvanus@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2009/10/23 David Nielsen &lt;<a href="mailto:gnomeuser@gmail.com">gnomeuser@gmail.com</a>&gt;:<br>
<div class="im">&gt;<br>
&gt;<br>
&gt; 2009/10/23 Michel Alexandre Salim &lt;<a href="mailto:salimma@fedoraproject.org">salimma@fedoraproject.org</a>&gt;<br>
&gt;&gt;<br>
&gt;&gt; Hi Aaron,<br>
&gt;&gt;<br>
&gt;&gt; Just noticed that Mono-Zeroconf bundles NDesk.DBus (I&#39;m not the Fedora<br>
&gt;&gt; maintainer for it, and just noticed since due to a glibc bug, we&#39;re<br>
&gt;&gt; having to turn off all but the AvahiDBus transport).<br>
&gt;&gt;<br>
&gt;&gt; Since this, unfortunately, is not allowed (without special approval)<br>
&gt;&gt; in our packages, I&#39;m thinking of updating our system NDesk.DBus to<br>
&gt;&gt; incorporate your patches. Do you happen to know who maintains<br>
&gt;&gt; NDesk.DBus right now? The copyright notice is unfortunately totally<br>
&gt;&gt; out of date (2006!)<br>
&gt;&gt;<br>
&gt; Alp Toker is still upstream for ndesk-dbus - I believe there is work ongoing<br>
&gt; on a new release but slowly.<br>
&gt;<br>
</div>Yes; bug filed here:<br>
<a href="https://bugs.launchpad.net/ndesk-dbus/+bug/458687" target="_blank">https://bugs.launchpad.net/ndesk-dbus/+bug/458687</a><br>
<br>
What disturbs me is that there does not appear to be an attempt by<br>
either Zeroconf and Sugar# to upstream their patches; meanwhile,<br>
Zeroconf ships with an internal copy (bad!) and Sugar# persuaded<br>
Fedora, somehow, to change the public interface of NDesk.DBus without<br>
an API bump.<br><font class="Apple-style-span" color="#888888"><br></font></blockquote><div><br></div><div>When I originally spoke to the sugar guys in relation to their patch they said that they had submitted patches to upstream, this one was a critical fix for them with a test case attached, it also withstood testing for a while without gathering complaints so it felt safe. I judged that allowing Mono development on Sugar was a worthwhile benefit for the risk such a change presented especially given it was my understanding the patch was bound upstream.</div>
<div><br></div><div>I think the issue is an overextended maintainer and a project that fundamentally works in it&#39;s current form.</div><div><br></div><div>- David</div></div>