[linux-dvb] patch collection for Kernel 2.6.16-rc1
uwe.bugla at gmx.de
Tue Feb 7 17:07:35 CET 2006
Hi, this is my last one for this thread (big promise):
@ Peter Beutner:
"But I think nobody intentionally will break a driver, that's why your
comparison doesn't really fit. Sending some personal rant about something
and attaching a patch is imho by far the worst attempt to get something
Yes and No:
Before you do not understand the whole thing, DO NOT JUDGE!
The patch by Peter Hettkamp that I mentioned above contained a so-called
"send-burst diseqc-function" that was cut out by somebody who apparently
does or did not know what he is doing, with destructive consequences.
As a consequence Mplayer refused to work with PCTVSAT at the transition from
one Kernel to the other. Xine did, kaffeine did, xawtv did, but Mplayer did
not! Cutting out code that at least one application needs to function at all
is slipshod, no good work at all. To make that clear I put down this
terrible joke with the flat. And the other example is a three months kernel
breakdown for the mentioned group of cards, which is not tolerable in my
point of view. It is OK so far to proclaim: "Feel yourself free to poke
around in other peoples code." But if the output of poking is destructive,
then who needs unusable code? In so far, bugs are human, for sure. But
responsiveless cut out of smaller or huge parts of missing code is something
worse than just a bug, and that is not tolerable. And at least my
associations trying to judge that are not positive.
Same thing with my documentation attempt, where even Johannes Stezenbach had
to admit public that it has been in such a terrible state (not open, but he
meant that I guess) that he felt he had to rewrite it and so simply gave up
(thank you, Johannes, you have proved to have personal greatness!). Manu
Abraham, one of the four coauthors, apologized for this bad work, but only
private, never did he do this public.
"And you still sent your patch as base64 encoded attachment not as plain
text? With no description what is changes?"
Big theory, no practical solution from yours. It has been plain text when I
sent it off as attachment, so what is wrong?
Ever stumbled across the drawbacks of a stupid mail program (wrong tabs,
wrong spaces etc.)? There is no sweat if the patch is rather small. Ever sat
down for hours to fix those drawbacks to make the damn patch apply? I
suppose you never did. For a list of changes, see Edgar's original from
January 8, 2006. Do I have to reinvent the wheel? I only adjusted stuff to a
newer kernel release not wanting to wait any longer after a quarter of a
So the next time before you judge just take time, and if you are not
satisfied, tell other people how to make better, OK?
And please remember: Who does something (whatever it may be), is attackable,
the one who does nothing only sucks. And that is the biggest fault about it
at all. We all have got to overcome exactly this one!
"We are working on this issue for a real solution, rather than a treatment
of the symptom."
Fantastic. Who is "we"? But for what happens in the meantime until that
"real solution" is mature, you obviously do not reflect for a second. And
the visible kernel result for me and others is a three month's breakdown.
Now if there is an obvious lack of manpower, should there not be smaller
steps to be done in development just to avoid breakdowns for such a long
time period? Please notice that I'm simply not used to that. And please
notice: What I and at least Hermann expect has got nothing to do with your
or others personal taste of what is a "real", "good", "mediocre" solution,
Now if you and others offer that such a long lasting breakdown in kernel
won't happen any more then I offer to test your stuff and give feedbacks.
Would that proposal be OK so far? How about in between solutions during
The basis for this deal must be a working environment, not a broken one, and
do not begin to tell me that this is not possible. And as far as time
windows are concerned: Nobody, no paid person nor any volunteer is a robot
bound to a time rhythm of kernel.org, linuxdvb.org or somewhere else. Good
development takes time. In my opinion fresh code, which is nor alpha,
neither beta or another state, should have nothing to do with code of the
running kernel. If it is ready for being tested there can be persons
recruited around here to test it. Where is the problem? But the basis always
must be a continuing running environment, in whatever state the development
code may ever be in. Do I expect too much? But if immature stuff reaches
kernel, that is even more than fatal I think.
And in so far I understand your sentence above as a bad excuse for something
that must not happen. How about supplying patch packages (or collections:
sorry!) here in testing estate, apart from CVS-Kernel? And if that proposal
is being approved, I need to know the standards a feedback has got to
conform to. A problem of organization, that's all.
Or is it better to merge a running CVS to a running Kernel? What is
important about the feedback on this? And even if you or others do not like
Edgars stuff that I overworked for 2.6.16-rc1 and meanwhile rc2, IT IS a
working in between solution, perhaps a bad one, but a working one, not a
broken one! And that should be the basis, not vice versa!
"Use femon's (dvb-apps) output value to make a metronome application, should
not be too hard .. use the value to control the metronome's frequency or
Big thank you for the hint, femon I've been knowing for years. But the
approach with the metronome application sounds a bit immature.
I am musician, and metronomes pin in the ass. What we need are unique
numbers not only in console printout state, but in spoken form for instance.
Ever heard about a tremendous work called MBROLA / festival? A speech
recognition engine. Something similar has been part of the Windoze driver
package published by Pinnacle since 2003: a female voice speaks numbers as
feedback for the input signal of the satellite dish. These spoken numbers
are in the same way unique as the console printout of femon is, there is no
need for concentration on the number of ticks per second. Very practical.
Or perhaps there is someone here to write something new taking up that
proposal....? One never knows....
@ Sid Boyce:
"Nowhere is the word salary or pay mentioned"
Very sorry, Sid, wrong! Please have a closer look at the maintainers file,
OKIDOK? And send in fixes if you know better, please. I only cited what I
"You are not alone, many people don't understand OpenSource......"
Sorry, at least wrong in my case. Too long to be discussed here..........
"I think we see first symptoms of a severe bureaucracy problem, as always
introduced by the hope of more rain soon. I'm still willing to read Uwe's
rant as some cry of despair and not as an cold assault.
... and I don't know how to serve it better with what we have."
Thank you very much! Very close! No despair at all, but criticism and
obviously unwanted questions. Don't take "rant", take "words".
@Johannes Stezenbach: Is there any concept, plan, possibility to delegate
the maintainers work on a few backs more? Who can be cosigner, who cannot?
Alternatives to the preceding standards? Are my questions trivial? Do my
expectations go too far?
I ask because I really do not want to witness burnout syndromes, not here,
and not anywhere else, no matter if coquetry is behind all or real wish for
Expecting a sophisticated answer and hoping we can finish that
Sorry for my "rant". Don't you and others "rant" sometimes too?? Just take
"words", not "rant", OK? And please notice that the capability of bringing
up ideas is not a privilege of a small group of developers. Who complains
wants changes. It's that simple.
P. S. to everybody: I do not like people mixing up criticism or unwanted
questions with negative energy. That is a state of mind I do not conform
Hope we can close this thread down now, as it begins to nerve at least me.
And if there are questions open, let us start another one.
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
More information about the linux-dvb