C'est encore plus drôle (mouais...) quand on regarde le nouveau site de plus près.
Roadmap?

Milestone 0.2.1
due in 2 months
* various bugfixes

Milestone 0.3
due in 5 months
* Couple of new features
* Initial python bindings

A vrai dire, je ne vois pas de (gros) problème. Si quelqu'un qui trouve un projet mort se sent de faire mieux, il peut tenter sa chance de son côté pour se tester. Son projet peut alors avancer plus ou moins vite, et puis finalement quand il se rend compte qu'il a une version qui "cartonne", voir avec les dev...
Il reste donc les méthodes de l'annonce, on (je) ne sait pas s'il a essayé de contacter les dev historique en direct, mais c'est clair que les mettre devant le fait accompli publiquement n'est pas très sérieux.
En dehors de ça, la liberté de forker c'est aussi la liberté de se planter : soit c'est un "géni" et il a raison de relancer un projet stagnant (les génis sont parfois abrupts), soit c'est un parasite et il sera rapidement éliminé par l'organisme hôte...

Ce n'est pas rare. Un grand exemple est ubuntu/debian.

Moi ce que je vois, c'est quelqu'un qui a décider de reprendre un projet, n'a pas vraiment regardé ce qu'il s'y passait, n'a parlé a personne et a annoncé son truc après avoir tout fait dans son coin.

Chapeau l'artiste!

Ils ont quand même fait l'effort de prévenir sur la ML ;-).

Quand un énergumène a décidé de forker Xtla, je l'ai découvert moi-même six mois plus tard en cherchant dans Google !

Bonjour,

(chapeau au direction de Joerg Schilling, le vrais maitre)

Mon francais est trop mal. Je vais continuer en anglais
si vous permettez.

My name is Thomas Schmitt, scdbackup at gmx dot net.

I am developing and maintaining a less known backup tool,
as my mail address suggests. This tool relies on Joerg
Schilling's cdrecord for CD burning.

During the last years, frightening quarrels erupted around
this only viable way to burn a data CD on Linux. It became
obvious that big trouble was on the horizon.
So i began to draft a petition to LKML, like:
"Please give us burn frontends some primitive replacement
for cdrecord. So we do not have to fiddle with raw devices,
O_DIRECT, cdrdao, et al., when cdrecord and Linux divorce."

I googled to become prepared for such a move. I found a
surprise:
http://icculus.org/burn/
Existing since begin of 2004. Quite inactive but with the
source of a program that was not totally useless: test/burniso.c
and a foundation library which seemed in workable shape.

Beginning with the traces in December 2005 mail archive
http://lists.freedesktop.org/archives/libburn/2005-December/(...)
i developed cdrskin
http://scdbackup.sourceforge.net/cdrskin_eng.html
which had quite exhausted the documented possibilities of
libburn and the abilities of myself in february 2006:
http://lists.freedesktop.org/archives/libburn/2006-February/(...)

By non-acceptance of my "whitelist"-patch, cdrskin was forced
to maintain an own fork libburn-0.2.ts. Nevertheless it was
prepared by macros to run on libburn-0.2 CVS version - if only
that patch had been included.

cdrskin was mentioned on LKML, Joerg Schilling stated that
libburn does not work (this was not really untrue, btw) and
the community issued a striking silence.
I mentioned it on cdwrite@other.debian.org (where i meet
Joerg Schilling and Andy Polykov, when i have a problem),
it did its job in confirming that a dead drive was dead.
Elsewise: nearly silence. People want full cdrecord.

cdrskin *did work* in versions 0.1.0, 0.1.1, 0.1.2, 0.1.3
on icculus.org/burn on kernel 2.4 and on kernel 2.6.
It had a homepage, it offered a source tarball, it offered
a static x86 Linux binary for quick test, it had docs.

Nobody ever gave it a chance, because it was no complete
cdrecord emulation. cdrecord is still better. No doubt.

Then the quarrel erupted. The seismologists knew in advance.
I knew not. Mario Danic knew.
Then this:
http://lists.freedesktop.org/archives/libburn/2006-July/0004(...)

What a challenge !
Two (2 !) bystanders stood up. One was me.
Both mildly questioning Mario's approach and waiting for
the thunder from our hosts.
Five days later, it made rather a noise like "crack"
http://lists.freedesktop.org/archives/libburn/2006-August/00(...)

I was very undecided and split myself. I dumped all open requests
(20+) to Mario's fancy ticket system and i stated my position as
user of libburn:
http://lists.freedesktop.org/archives/libburn/2006-August/00(...)

After i bonked Mario with a "What is wrong with my whitelist patch ?"
he included it in
http://libburn.pykix.org
and i could give up my involuntary libburn fork !

Mario did not fork. I did in december 2005. He merged me in.
I became his team mate with what you deem so abominable.
And i again stated my position publicly:
http://lists.freedesktop.org/archives/libburn/2006-August/00(...)
This is the *most recent* post on that list. 3 weeks old.
Qu'est-ce que c'est - l'autisme ?

We *do not* have a libburn fork right now. A fork needs two prongs.
We got what german language botanically calls a "geiler Trieb"
- a single green branch out of the tip of the stem.

cdrskin is now covered as "unstable" by major distros, google
does not trigger a spelling correction any more, Debian's
package page outranks cdrskin's homepage on google (congrats :))
When i ask for drive tests i get replies with 10+ manufacturer
names, in part i never heard of them.


This all is Mario Danic's merit. Kudos.

I had waited 4 weeks for a reply of Derek. That would mean we
were 4 weeks behind of where we are now. Mario was right -
i would have been wrong. Nobody asked me, luckily.


Meanwhile i found out that cdrskin worked by mere accident.
Leaving its way of using libburn caused immediate failure.
I found resource leaks with file descriptors, fandango on core,
systemwide interference with any /dev/sgN or /dev/hdX that
could appear as a CD drive.
My cdrskin avoided all those pitfalls by accident and by
its "whitelist" patch, which emerged from my uncomfortable
feelings towards libburn's mandatory bus scan.

Meanwhile we offer a honest README
http://libburn.pykix.org/browser/trunk/README?format=raw
which gives an overview on project and our justification of
what we decided to do.

Meanwhile we offer a non-self-sarcastic introduction
of the libburn API
http://libburn-api.pykix.org
This is a complete rewrite of
http://icculus.org/burn/doc/
where i myself started my own libburn encounters in 2005.
If you see remaining copyright of Derek Formeman and Ben
Jansens in the comparison of both, please contact me
via mail to above address or via libburn-hackers at pykix dot org.


We do not hide the ancestry of our project. We pay due respect
to its initiators (who still are in part our originators).
We become ancestors ourselves the way that franconians became
ancestors of great nobility: by taking what others don't grab
strong enough. C'est GPL, n'est-ce pas ?

We will work our way down, grok and rewrite in our own words
and only copying single lines, if ever, to avoid typos.


About me:

I myself am not affiliated with any distro or party in the
cdrecord quarrels. I feel free to cooperate with Eduard Bloch
and with Joerg Schilling at the same time. We three are germans,
so it is not without friction.
I never exchanged personal insults with them, though,
and i believe both deem me worth of cooperation. At least within
the limits of my own claims as actually an app programmer.

For my copyright-related activities i am open to criticism
and discussion. The question is:

How do we get the only known technical alternative to cdrecord
into a shape that license questions can be solved in a timely
way that surely complies with the *idea* of open source ?

Alternative. Timely. Idea. Those are the key words.


I am open and free. Are you ? Then give us a chance.

Even on fancy realtime channels where i refuse to watch,
because i am an old C fart who will celebrate his 20 years
Unix jubilee this november, who still has a bootable
Linux 0.99 at hand and who never installed a Linux himself.

This statement is not coordinated with my team mate Mario Danic.
It is my own personal view of things and needs neither an team ok
nor is it subject to a team veto.
It is also my challenge to Mario's critics to stay fair and
to cut out community stereotypes.

I will inform Mario now, after posting it.
I will urge him, to mention a link to it whenever he has the
slightest suspicion that a critic of him did not read it yet
and possibly did not follow the many URLs in it.


Chapeau ... to Joerg Schilling and Andy Polyakov, burn masters.