<br><br><div><span class="gmail_quote">On 7/31/06, <b class="gmail_sendername"><a href="mailto:scdbackup@gmx.net">scdbackup@gmx.net</a></b> &lt;<a href="mailto:scdbackup@gmx.net">scdbackup@gmx.net</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br><br>&gt; the project has been revived and now lies at <a href="http://libburn.pykix.org">libburn.pykix.org</a><br>&gt; Please post bugs, ask for enchantments/features, etc. :)<br><br>Well, libburn could need some increased agility, that much
<br>is true.<br><br><br>&gt; As far as I could understand, the commits stopped two year ago,<br>&gt; and nothing was happening on the libburn front since then.<br><br>There have been changes and enhancements in the beginning
<br>of this year (2006). My own project cdrskin currently uses<br>a privately forked libburn-0.1.2 or a libburn-0.1.3 from CVS<br>of february 2006 (with still one private enhancement, sigh).<br><br>So it is not dead ... only very slow.
<br>Hopefully some of the maintainers will notice your announcement<br>and a fruitful discussion can emerge.</blockquote><div><br>I would hope the same...<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&gt; I really don't see this as a forking :)<br>&gt; We will continue with current codebase, and continue the things that<br>&gt; were started, nothing else :)<br><br>It will be a fork as soon as the traditional maintainers
<br>make a change on their own version.<br>So in order to be not a fork, it would need coordination.<br><br>Being an involuntary libburn forker myself, i can hardly speak<br>against a fork in general. Nevertheless, i do express my support
<br>for having a unified and stable API and for rejoining the forks<br>into a common version from time to time.<br><br>I myself do not strive for participating in the inner development<br>of libburn but am mainly interested in getting the needs of
<br>cdrskin into a stable version of libburn. (There are two pending:<br>my whitelist patch and my wish to burn on-the-fly with data<br>read from stdin and no need to announce the track size in advance.)<br><br>What are your plans about the next enhancement steps ?
<br>Would it be possible to expose a tarball with a snapshot of<br>the current state of <a href="http://libburn.pykix.org">libburn.pykix.org</a> ?<br><br><br>Have a nice day :)<br><br>Thomas<br><br>_______________________________________________
<br>libburn mailing list<br><a href="mailto:libburn@lists.freedesktop.org">libburn@lists.freedesktop.org</a><br><a href="http://lists.freedesktop.org/mailman/listinfo/libburn">http://lists.freedesktop.org/mailman/listinfo/libburn
</a><br></blockquote></div><br>