Re: cdrtools cdrecord/cdrecord.c
Steve McIntyre <steve@einval.com> wrote:
> >Again:
> >
> >- Linux kernel folks modify interfaces without notifying the users
> > even though there are less than 5 Authors who write software that
> > uses the related interfaces.
>
> Joerg, please - I believe you're wrong here. If it's your opinion that
> less than 5 authors use the Linux sg interface (the one I'm assuming
> you're describing here), then in my experience you're simply
> wrong. I've _personally_ been involved in several different projects
> that use the sg interface, none of which you would know about. I would
> expect there to be many more out there...
If you believe so, can you list more than 5 projects?
What the Linux folks did was an absolute no-go: they incompatibly changed
an interface withing a single release.
Fou you are not on a toy-OS, you even need to announce such changes
long before doing it and making sure that there is no other way.
Linux Torvalds did needlessly change the interface although a clean
fix for the problem he pretends to fix would not cause the need to change
the interface.
> >- Most Debian patches _cause_ problems instead of fixing them.
>
> Again, I disagree. There are bugs in our BTS to back me up. Please can
> you point to some patches that _actually_ cause problems?
I send mails to the bug list explaining which "bug" are no bugs or are
rather bugs in the Linux kernel.
I send mail to explain which "bugs" are no bugs at all.
If Debian likes to be taken for serious, there is a need to do housekeeping:
- close the "bugs" that are no bugs
- Move the Linux kernel bugs to the linux kernel bug list.
> >- Debian people do not cooperate by not talking to the Authors of the
> > software.
>
> In general, or just cdrtools? Generally, we have useful, productive
> relationships with upstream developers. In many cases, Debian patches
> are gratefully accepted and integrated into new upstream releases. In
> some cases, some of the patches we apply are clearly not useful to
> upstream developers (e.g. changing install locations, etc. to
> integrate more closely with the rest of the system). Sometimes we even
> end up taking over upstream packages if the original developer has
> given up.
Looks like a general problem.
The star maintainer from Debian happily ignores new releases and creates
patches that prevent star from compiling. He then claims that this was a
problem by the original star.
Instead of asking me for help why star does not compile, he puts his unsulting
remarks into the Debian bug tracking system.
Currently star on Debian is 3 releases outdated.
The smake maintainer is in deep hibernation. He did ignore new releses
sice nearly 2 years. Currently smake on Debian is 11 releases outdated.
The smake maintainer on Debian states that smake is broken while the
reason for the problems is a completely broken /bin/sh (a link to bash)
It is most unlikely that other Debian maintainers act better if 3 of 3
packages on Debian are not maintained properly.
> To return to previous discussion, but hopefully more calmly this time:
Well, if you don't start insulting me as you did yeaterday there is no problem.
> Joerg, you may think that you're simply speaking plainly and directly
> in some of your mails. I know that German is already commonly a much
> more direct language than English; maybe your choice of words is
> affected by that. I _hope_ that your intent is not to insult the
> people who are trying to work with you, but the tone of your emails
> often makes it seem that way.
Are you shure about what you are saying here?
_you_ did start to reply in a real crude way to my first mail.
My reply was stil careful and not as insulting as yours.
It seems to be the time that you prove that your intent is to have a useful
discussion.
> Sometimes people who are making changes to cdrtools simply don't agree
> with some of the design decisions you've made. That doesn't
> necessarily make them stupid or wrong. Some _might_ be (there are lots
> of idiots in the world, after all! :-) ), but not all. Some more
> flexibility and consideration of other people's suggestions might help
> you get on much better with people...
Well, speaking of flexibility, start acting this way and we will not have any
problems.
The design decisions in cdrecord are consistent since more than 10 years.
If you like a different design, start your own writing program project.
Changing things that are not currect today and will be fatal tomorrow when
cdrecord eveolves in the official and long planned way. This is like
using the left way on a gabling while you know that the group you acompany
will take the right way on the next gabling.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Reply to: