[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: J?rg Schilling is damage; the community should route around him

-------- Original Message --------
Subject: Re: J?rg Schilling is damage; the community should route around him
Date: Mon, 11 Oct 2004 01:45:22 -0400
From: Sean Harshbarger <harshy@dersoldat.org>
To: Steve Kemp <skx@debian.org>
References: <[🔎] 20041009050455.GR19131@redwald.deadbeast.net> <[🔎] 1097320730.7262.8.camel@localhost> <[🔎] 20041010201924.GA32531@steve.org.uk>

Steve Kemp wrote:
On Sat, Oct 09, 2004 at 01:18:50PM +0200, Jose Carlos Garcia Sogo wrote:

El s??b, 09-10-2004 a las 00:04 -0500, Branden Robinson escribi??:

It's time to fork.  Let us work with the rest of the community to
standardize on a new set of tools based on the last free version of
cdrtools, thank Mr. Schilling for his valuable contributions, and leave him
be to pursue his interests in proprietary software without interference
or argument from us.  He appears to regard placing his work under the plain
vanilla GNU GPL that works for so many projects as an act that he cannot
perform in good conscience.  Let us stop placing him in that uncomfortable

 I agree with you. And I guess that the "good" direction would be
pushing libburn, which seems a bit stalled right now. Also, DVD[-R[W],
+R[W]] support should be added to it. On top of that library, it would
be easier to build command line and GUI oriented programs, which could
drop at that moment cdrecord.

  I wrote about this only a few days ago in a brief piece which was
 included in planet.d.o.

  At the time I was directed very quickly towards libburn.  Using
a library seems a lot saner than taking over any of the cdrecord codebase. If necessary a command line wrapper around the library
 could emulate the cdrecord command line options.

  I couldn't gain access to the libburn CVS repository, but I did
 download the .0.2 version and the test code worked for me.  I was
 able to burn an image using it fairly quickly, although I can't say
 how stable the code is generally.  (The API documentation was nice).

 But what is needed there is people with time and access to different
drives. Perhaps people behind dvd+rw-tools could be interested, and some
company out there could sponsor this piece of software.

  I think a few individuals would be happy to host the code and work
 on it, but hardward testing really is the stumbling block - as is
 portability testing.

 The problem with cdrecord is that it works, and though there are some
glitches that people would like to see fixed, writing another different
tool is only that: rewriting. And using the same language, i.e. there is
no perl vs. python, perl vs. php, ...

It does seem a little tedious reimplimenting code which already exists, and mostly works. This either suggests:

  1) It isn't worth doing, and we just put up with the maintainer.
  2) It shuld be done in a better way (library based?)
  3) Forking a free-er/older version.

Given the vehemence of J?rg to SuSE and the other people "illegally distributing inofficial versions (sic)" I strongly suggest
 option 3 is not a good idea - if nothign else it will lead to confusion
 amongst users.

  Perhaps having a Debian package of libburn would be a good starting
 point - then popular programs can be patched to work with it?

I already put the libburn package in unstable a couple months back in
hopes that more people would adopt/help it out. The libburn team has
been somewhat idle last month or so, and I think this is the type of
poking they need to continue it.

The api is IMO nice, but the library is still missing some things. Only
thing they might want to do later on is goto a lgpl versus the gpl they
have now.

A wrapper around libburn could give us the possibility of using that in
place of cdrecord. A few have mentioned interest in this so that they
could easily convert favorite apps, IE nautilus-cd and xcdroast.

As the main developer of the Coaster Project for gnome, I have already
embraced libburn as a viable solution to this new age of disc burning,
and only want to see more developers jump on the bandwagon to help
libburn get better.


Attachment: signature.asc
Description: PGP signature

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: