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 fixed." 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 year. 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! @Manu Abraham: "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, OK? 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 development? 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 interval." 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 read. "You are not alone, many people don't understand OpenSource......" Sorry, at least wrong in my case. Too long to be discussed here.......... @Hermann Pitton: "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 more relief. Expecting a sophisticated answer and hoping we can finish that thread........... 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 with. 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 _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
