I&#39;ve half a mind to fork it and make some additions that fit it better with my habits (more command-line alternatives to the interactive stuff)... but only half a mind.  I&#39;ve enough open source projects that I don&#39;t have enough time to work on, as it is.<div>
<br></div><div>Out of curiosity, how many people offer you patches?  If it were just a matter of release management, I might be able to manage a fork, with my occasional tweak, reviewing patches, and the occasional release... but if the fork depends entirely on my development effort, then it probably isn&#39;t worth it, since the updates would be extremely rare.<br>
</div><div><br></div><div>Is there <b>anybody</b> on this list, besides myself, who has both interest and skill to respond to bug reports and do modest development?  If so, please contact me.</div><div><br></div><div>Also, since I value your opinion on these matters, William -- what are you using now for issue management, and why?  I ask, because I&#39;m considering whether some sort of direct offline Trac tool might be lower cost for me.  I like ditz just fine, but I&#39;m not sure that I need my issue tracker to be version controllable -- I just need it to be off-line-able, and have a separate DB per project.  In fact, I&#39;m increasingly convinced from what I&#39;ve seen that software developers have no more -- and possibly less -- than a 50% stake in issue management; users have the other solid 50%.  As for ease-of-use, ditz-like trackers have a split more like 95/5; web-based trackers split it more 80/20.  The more I think about it, the more I believe that a solid web tracker which can be used off-line and sync&#39;ed is the ideal design.  Trac, or Redmine, or some such.</div>
<div><br></div><div>My experience with ditz-trac has shown me that the XMLRPC interface to Trac simply isn&#39;t sufficient for a robust off-line sync&#39;ing.  It imposes too many limitations on the event log.  What I really need is direct write access to the Trac DB, so that I can manage the events with finer resolution.  If I go down that path, though, then one wonders whether it might not be better to simply copy the sqlite DB, rather than trying to shoe-horn the two differing schemas (Trac/ditz) together.</div>
<div><br></div><div>Well, thanks for responding, William.</div><div><br></div><div>--- SER  </div><br><div class="gmail_quote">On Sun, Jan 31, 2010 at 10:21 AM, William Morgan <span dir="ltr">&lt;<a href="mailto:wmorgan-ditz@masanjin.net">wmorgan-ditz@masanjin.net</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Reformatted excerpts from Sean Russell&#39;s message of 2010-01-30:<br>
<div class="im">&gt; It was worth the effort; William has obviously either worked with<br>
&gt; plugin infrastructures before, or he&#39;s a plugin prodigy... the<br>
&gt; interface is extremely complete and easy to use, and it&#39;s taught me a<br>
&gt; lot about the domain. If you haven&#39;t played with plugin development, I<br>
&gt; recommend it as a study in good plugin architecture design.<br>
<br>
</div>Wow, thanks! I am pretty happy with how the plugin stuff turned out in<br>
Ditz. Thanks for ploughing through the lack of remaining support<br>
community, and keep us informed about the plugin!<br>
<font color="#888888">--<br>
William &lt;<a href="mailto:wmorgan-ditz@masanjin.net">wmorgan-ditz@masanjin.net</a>&gt;<br>
_______________________________________________<br>
ditz-talk mailing list<br>
<a href="mailto:ditz-talk@rubyforge.org">ditz-talk@rubyforge.org</a><br>
<a href="http://rubyforge.org/mailman/listinfo/ditz-talk" target="_blank">http://rubyforge.org/mailman/listinfo/ditz-talk</a><br>
</font></blockquote></div><br>