Mauro Carvalho Chehab wrote:
> Enough. Let's stop arguing non technical issues.
>
> If either one of you have any technical argue against the Trent's
> patches, please point where the fix is wrong. Otherwise, if you wish,
> you may send an acked-by agreeing with the fix.
>
Why don't you stop this childish behaviour ?
After explaining to you the reasons in the previous mail:
being the author and maintainer of dst/dst_ca and maintainer of
dvb-bt8xx, i NACK this change
(1) You aren't DVB maintainer
(2) one shouldn't make such judgement calls on somebody else's driver
unless it falls within your own maintainership
> Mauro.
>
> Em Qui, 2007-05-03 às 19:19 +0200, Markus Rechberger escreveu:
>> On 5/3/07, Manu Abraham <[email protected]> wrote:
>>> Markus Rechberger wrote:
>>>
>>>> Manu,
>>>>
>>>> to me it looks like your attitude is not acceptable here, I sent
>>>> several mails already which you just use to ignore.
>>> You very well know the reason why i am ignoring your mails. You just
>>> tend to flame people for nothing. I tend to ignore the flamers.
>>>
>> You should stop to rely on the history, since such a flame needs at
>> least 2 parties and back then you were also involved. There's nothing
>> else to say about that.
>>
>>>> If you don't change that attitude immediatelly I'd really wish to get
>>>> you banned of this community until you're open for discussions.
>>>>
>>>> http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html
>>>>
>>>> there's a bugreport and you fully ignore it, and you blame it on the
>>>> "politicians" here, telling me that there are mails out there
>>>> somewhere shows that you're not interested in getting forward.
>>>>
>>> That bug report very well proves my point.
>> Well it would be nice if you could answer the question in that mail
>> then, I don't see any reason why you shouldn't answer it.
>>
>> It's just a guess, but it seems like that you had a problem with other
>> developers at that part and it seems like it didn't get to an end
>> (probably because both parties didn't agree with each other)
>>
>> Markus
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
On 5/3/07, Manu Abraham <[email protected]> wrote:
> Mauro Carvalho Chehab wrote:
> > Enough. Let's stop arguing non technical issues.
> >
> > If either one of you have any technical argue against the Trent's
> > patches, please point where the fix is wrong. Otherwise, if you wish,
> > you may send an acked-by agreeing with the fix.
> >
>
> Why don't you stop this childish behaviour ?
>
> After explaining to you the reasons in the previous mail:
> being the author and maintainer of dst/dst_ca and maintainer of
> dvb-bt8xx, i NACK this change
>
> (1) You aren't DVB maintainer
I've seen that too often already, now we could point to a mail someone
sent to Uwe regarding maintainership.
You wouldn't be better at the moment, Mauro at least aknowlidges the
work of others.
I don't know what problems you have with Mauro I heard that there have
been some mails between you and some other developers as well and the
whole situation is just terrible.
If you want to change the whole situation, think about what you can do
for improving the whole situation even if it means that you have to
work with people you don't like.
> (2) one shouldn't make such judgement calls on somebody else's driver
> unless it falls within your own maintainership
>
I wrote what I'd like to see from you, it would be a start if you
could work on that first.
Markus
Markus Rechberger wrote:
> On 5/3/07, Manu Abraham <[email protected]> wrote:
>> Mauro Carvalho Chehab wrote:
>> > Enough. Let's stop arguing non technical issues.
>> >
>> > If either one of you have any technical argue against the Trent's
>> > patches, please point where the fix is wrong. Otherwise, if you wish,
>> > you may send an acked-by agreeing with the fix.
>> >
>>
>> Why don't you stop this childish behaviour ?
>>
>> After explaining to you the reasons in the previous mail:
>> being the author and maintainer of dst/dst_ca and maintainer of
>> dvb-bt8xx, i NACK this change
>>
>> (1) You aren't DVB maintainer
>
> I've seen that too often already, now we could point to a mail someone
> sent to Uwe regarding maintainership.
FYI, I have never written to Uwe regarding any sort of maintainership.
You seem to be quite up with an overdose of drugs
>From 2005/09/13 - 2007/05/03 (till date) there have been 15 mails from
my side to Uwe, none of which has a topic whatsoever you say. Only the
first mail was a private mail and that is CC'd to Johannes as well.
Firstly you seem to play politics by getting Uwe to flame me, then when
it backfired, you are trying to play tricks with the rest of the
community as well, by spreading nonsense statements.
Great!
On 5/3/07, Manu Abraham <[email protected]> wrote:
> Markus Rechberger wrote:
> > On 5/3/07, Manu Abraham <[email protected]> wrote:
> >> Mauro Carvalho Chehab wrote:
> >> > Enough. Let's stop arguing non technical issues.
> >> >
> >> > If either one of you have any technical argue against the Trent's
> >> > patches, please point where the fix is wrong. Otherwise, if you wish,
> >> > you may send an acked-by agreeing with the fix.
> >> >
> >>
> >> Why don't you stop this childish behaviour ?
> >>
> >> After explaining to you the reasons in the previous mail:
> >> being the author and maintainer of dst/dst_ca and maintainer of
> >> dvb-bt8xx, i NACK this change
> >>
> >> (1) You aren't DVB maintainer
> >
> > I've seen that too often already, now we could point to a mail someone
> > sent to Uwe regarding maintainership.
>
>
> FYI, I have never written to Uwe regarding any sort of maintainership.
> You seem to be quite up with an overdose of drugs
>
I mean the mail from Helge Hafting (thread [linux-dvb] Critical
points about kernel 2.6.21 and pseudo-authorities) at the very first
beginning.
> From 2005/09/13 - 2007/05/03 (till date) there have been 15 mails from
> my side to Uwe, none of which has a topic whatsoever you say. Only the
> first mail was a private mail and that is CC'd to Johannes as well.
>
> Firstly you seem to play politics by getting Uwe to flame me, then when
> it backfired, you are trying to play tricks with the rest of the
> community as well, by spreading nonsense statements.
>
I sent several comments to Uwe to stop flaming, Trent was in the CC
sometimes I never wrote that he should flame on anyone.
I can simply forward you all mails I sent to Uwe there's not one bad mail.
My point is moreover to get that issue sorted out by either accepting
his "proposal" or stating out why not to add it (and there must be a
reason behind it, and no mail which is 2 years old, or explaining what
the device is, again it got explained what's required from you)
seems like your response is based on that misunderstood sentence,
sorry for not beeing clear enough.
Markus
Markus Rechberger wrote:
> I mean the mail from Helge Hafting (thread [linux-dvb] Critical
> points about kernel 2.6.21 and pseudo-authorities) at the very first
> beginning.
>
I am replying to this mail, just because someone's spreading lies all
around.
On the mentioned thread, what i wrote (and that was the only mail from
my side):
There is a saying: "He who lives by the sword, dies by the sword."
-------- Original Message --------
Subject: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and
pseudo-authorities
Date: Tue, 01 May 2007 04:19:41 +0400
From: Manu Abraham <[email protected]>
To: Uwe Bugla <[email protected]>
CC: [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected]
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <1177894713.3046.5.camel@p
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
Uwe Bugla wrote:
> 1. You utmost personally are responsible for 4 ununsable kernels, as
far as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16!
> 2. You did not even want to imply to resolve that issue by incarnating
that "community and synergy principle" that linux community needs to
exist at all, but you just perverted it by flaming capable people -
You mean like this:
-------- Original Message --------
Subject: kernel patch practice in 2.6.13-mm2
Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST)
From: Uwe Bugla <[email protected]>
To: [email protected]
CC: [email protected]
Hi,
if you continue to send or sign mm-patches for Kernel 2.6.13 as a
consequence of a design change I would appreciate you to stop rubbing out my
name.
You did that in a file called /Documentation/dvb/bt8xx.txt.
My objective is understandable good documentation, even if it may sound
trivial for some developpers minds. I always have in mind that there are
also lots of beginners reading those documents.
As I respect your work I never in my life would even dare to rub out other
coauthors names.
That?s why I appreciate you to respect my name and stop rubbing it out.
Thanks
Uwe Bugla
P. S.: If you f. ex. publish a book I ain?t gonna burn it as a matter of
disrespect. So have a little respect vice versa!
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen f?r GMX Partner: http://www.gmx.net/de/go/partner
------- Original Message --------
Subject: "synchronization problems"
Date: Thu, 15 Sep 2005 10:44:38 +0200 (MEST)
From: Uwe Bugla <[email protected]>
To: [email protected]
CC: [email protected]
Hallo Mr. Stezenbach,
"You breached the protocol by not sending the patches to the maintainer
or linux-dvb list. The result of this was that we had conflicting
changes in CVS. I spent about 10 minutes thinking how I could
merge the two, and then gave up (I had 53 other patches to prepare
and I had little time left to do the job). So I didn't just remove
your name, but all changes which you sent to akpm along with it.
bt8xx.txt in the kernel is now in sync with the version in linuxtv.org CVS."
I didn't breach any protocol, nor did I break any unwritten rule or law. I
simply took the advice from Gerd Knorr that linuxtv maintainers were just
moving to another place to the point of time when I sent in my first
dvb-bt8xx-patch. So consequently I took the direct way to send it to akpm.
Just to be sure it is really being applied without waiting 3, 4 weeks or
however long. So if you continue to at least discussing with my person,
please immediately stop doing that in such a bureaucratic manner. If
synchronization of CVS and kernel.org only works unidirectional, and not
bidirectional, then neither I, nor akpm, nor Manu or anybody else has a real
problem, but you personally have one without any doubts.
And if you lack time, simply delegate your job to another person. But simply
stop rubbing out other peoples coauthorship and pay respect to their
contributions. And the biggest joke about your personal misbehaviour is the
fact that you personally cosigned at least one of my patch attempts, without
dropping me a single note asking me to not bypass the linuxtv CVS
maintainers. So good morning Mr. Stezenbach, I appreciate you to wake up a
little bit earlier in the future!
"Additionally you deleted information from bt8xx.txt which I think were
useful help for debugging problems, and which were written there on purpose
by the developer. So if you talk about respect, you could show some yourself
by not bypassing the original authors and maintainers when sending patches."
In fact I did, and I can tell you the simple reasons why.
There are in fact two things that I simply cannot and will not tolerate:
a. orthographic junk (examples: "bythe" or, even worse: "autodected" and
"Recognise") It was ME who corrected that in the past, and it was YOU
personally who reversed that, if not to say: fucked it up in the current
2.6.14-rc1. So as a consequence it is YOUR task to do your homework and
apologize for that, but not MINE!
b. attempts of documentation that do NOT correspond to their appropriate
kernel design
What do I mean with b.?
1. In Kernels 2.6.12 AND 2.6.13 the simple command "modprobe dvb-bt8xx"
caused ALL OTHER modules to load automatically:
cx24110, dst, dst-ci and dst-ca. Now if the kernel design forces the
automatic loading of dst, dst-ca and dst-ci, every attempt of discussion
about debug parameters is simply obsolete! So if I cannot load the dst
module separately, how should I be able to hack in
debug parameters? I know what debug parameters are for, and I deeply respect
developers work, but what the hell is it all worth for if a kernel design
suppresses hacking in debug parameters?
2. Moreover I am not shure in how far the parameters 0x68 and 0x71 really
correspond to TwinHan cards. A closer look to CARDLIST.bttv says: card ID =
113. But perhaps I have problems to deal with hexadecimal numbers, and this
would simply be my problem, not yours!
4 rules for a real good documentation:
1. understandable and transparent information for different understanding
levels
2. strictly corresponding to the laws of the current kernel design
3. absolutely errorfree concerning orthographic junk
4. structured in a senseful manner (f. ex.: headliner corresponds to real
contents)
If an attempt of documentation lacks at least one of the four, it is simply
useless to my opinion. Why aren't debug parameters part of another part of
documentation, f. ex. ci.txt? Or ca.txt? The headline of dvb-bt8xx.txt goes:
"How to get the Nebula, PCTV, and TwinHan DST cards working."
My question: If the essence of a documentation text is how to bring up a
specified card, then please what the hell has that got to do with debug
parameters? Who are the addressed groups of such a text? To my opinion at
least the headliner says that the following text addresses users and nobody
else!
So I simply never intended to bypass any developer, but I simply found out
that the bt8xx-documentation simply did not correspond to the actual kernel
design. In other words: Was unusable. So I decided to write a patch and
simply act instead of performing endless discussions, and that's all about
it!
And: If you reinvent the name of cards: Do it for whatever reason, for god's
sake! But: How the hell do you define to a person not convenient with all
that special technical vocabulary, what the hell a BT8xx-card is? Remember
the first of my 4 rules (see above!). So at least a complete list of cards
conforming to that standard is necessary for transparent information:
Question: Pinnacle PCTV SAT, Nebula Electronics DigiTV, TwinHan DST and
clones, Avermedia of all kinds..... Is that list complete? If not, please
drop me a note where I can get that complete list of cards corresponding to
that standard, and I'll instantly sit down and write a patch to improve
documentation.
But before I even think about doing that I appreciate you to do your
homework:
a. readd my name (I didn't delete it, so I won't do the same job again, not
for sync reasons, and not for reasons of lack of time, and not for any other
reason.
b. fix orthographic errors in dvb-bt8xx.txt (for the same reason mentioned
in point a.)
c. reconstruct my 2.6.13-structure of dvb-bt8xx.txt as far as possible
d. reflect very well, whether debug parameters should not better be situated
in different documentation texts (logically structured, understandable)
Regards
Uwe Bugla
P. S.: akpm never complains about lack of time, and he is doing a very fair
and good job, and, at least for him, the amount of 54 patches is simply
peanuts. I love cooperation with guys like him!
In other words: I respect the demand that cvs-tree and current kernel must
be in sync somehow, but if the output is rubbish for several reasons and,
moreover, neglects my work, there is simply no reason for any kind of
respect. Because I ain't no idiot, just to say it in very simple words.
So please in future avoid to blame my person for things that you personally
don't get worked (synchronization or whatever kind).
And would you please answer me one question: How can I be shure that my
patchwork at least enters the institution akpm, if there is someone like you
in between complaining for lack of time and synchronization faults? I prefer
flat hierarchies (the real hidden success principle of Linux) and
cooperation with akpm works very fine.
So, as a matter of principle, I don't see any reason why I should prepare
and send in my work three, four, five times, just because at the other end
someone doesn't get his stuff synchronized or lacks time. I ain't no idiot!
Ya Basta!
And even if I would give in now for strategic reasons and do the same
fuckin' work again, how many Stezenbach clones or whoever would come up
afterwards and continue to fuck up my work in the same or just in a
different way you personally did? Who do you think you are and who do you
think I am? So please do your homework, and do it correct in the future, or
leave that job simply to another person. OK?
Any further questions, Mr. Johannes Stezenbach?
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen f?r GMX Partner: http://www.gmx.net/de/go/partner
Hallo Mr. Stezenbach,
"You breached the protocol by not sending the patches to the maintainer
or linux-dvb list. The result of this was that we had conflicting
changes in CVS. I spent about 10 minutes thinking how I could
merge the two, and then gave up (I had 53 other patches to prepare
and I had little time left to do the job). So I didn't just remove
your name, but all changes which you sent to akpm along with it.
bt8xx.txt in the kernel is now in sync with the version in linuxtv.org CVS."
I didn't breach any protocol, nor did I break any unwritten rule or law. I
simply took the advice from Gerd Knorr that linuxtv maintainers were just
moving to another place to the point of time when I sent in my first
dvb-bt8xx-patch. So consequently I took the direct way to send it to akpm.
Just to be sure it is really being applied without waiting 3, 4 weeks or
however long. So if you continue to at least discussing with my person,
please immediately stop doing that in such a bureaucratic manner. If
synchronization of CVS and kernel.org only works unidirectional, and not
bidirectional, then neither I, nor akpm, nor Manu or anybody else has a real
problem, but you personally have one without any doubts.
And if you lack time, simply delegate your job to another person. But simply
stop rubbing out other peoples coauthorship and pay respect to their
contributions. And the biggest joke about your personal misbehaviour is the
fact that you personally cosigned at least one of my patch attempts, without
dropping me a single note asking me to not bypass the linuxtv CVS
maintainers. So good morning Mr. Stezenbach, I appreciate you to wake up a
little bit earlier in the future!
"Additionally you deleted information from bt8xx.txt which I think were
useful help for debugging problems, and which were written there on purpose
by the developer. So if you talk about respect, you could show some yourself
by not bypassing the original authors and maintainers when sending patches."
In fact I did, and I can tell you the simple reasons why.
There are in fact two things that I simply cannot and will not tolerate:
a. orthographic junk (examples: "bythe" or, even worse: "autodected" and
"Recognise") It was ME who corrected that in the past, and it was YOU
personally who reversed that, if not to say: fucked it up in the current
2.6.14-rc1. So as a consequence it is YOUR task to do your homework and
apologize for that, but not MINE!
b. attempts of documentation that do NOT correspond to their appropriate
kernel design
What do I mean with b.?
1. In Kernels 2.6.12 AND 2.6.13 the simple command "modprobe dvb-bt8xx"
caused ALL OTHER modules to load automatically:
cx24110, dst, dst-ci and dst-ca. Now if the kernel design forces the
automatic loading of dst, dst-ca and dst-ci, every attempt of discussion
about debug parameters is simply obsolete! So if I cannot load the dst
module separately, how should I be able to hack in
debug parameters? I know what debug parameters are for, and I deeply respect
developers work, but what the hell is it all worth for if a kernel design
suppresses hacking in debug parameters?
2. Moreover I am not shure in how far the parameters 0x68 and 0x71 really
correspond to TwinHan cards. A closer look to CARDLIST.bttv says: card ID =
113. But perhaps I have problems to deal with hexadecimal numbers, and this
would simply be my problem, not yours!
4 rules for a real good documentation:
1. understandable and transparent information for different understanding
levels
2. strictly corresponding to the laws of the current kernel design
3. absolutely errorfree concerning orthographic junk
4. structured in a senseful manner (f. ex.: headliner corresponds to real
contents)
If an attempt of documentation lacks at least one of the four, it is simply
useless to my opinion. Why aren't debug parameters part of another part of
documentation, f. ex. ci.txt? Or ca.txt? The headline of dvb-bt8xx.txt goes:
"How to get the Nebula, PCTV, and TwinHan DST cards working."
My question: If the essence of a documentation text is how to bring up a
specified card, then please what the hell has that got to do with debug
parameters? Who are the addressed groups of such a text? To my opinion at
least the headliner says that the following text addresses users and nobody
else!
So I simply never intended to bypass any developer, but I simply found out
that the bt8xx-documentation simply did not correspond to the actual kernel
design. In other words: Was unusable. So I decided to write a patch and
simply act instead of performing endless discussions, and that's all about
it!
And: If you reinvent the name of cards: Do it for whatever reason, for god's
sake! But: How the hell do you define to a person not convenient with all
that special technical vocabulary, what the hell a BT8xx-card is? Remember
the first of my 4 rules (see above!). So at least a complete list of cards
conforming to that standard is necessary for transparent information:
Question: Pinnacle PCTV SAT, Nebula Electronics DigiTV, TwinHan DST and
clones, Avermedia of all kinds..... Is that list complete? If not, please
drop me a note where I can get that complete list of cards corresponding to
that standard, and I'll instantly sit down and write a patch to improve
documentation.
But before I even think about doing that I appreciate you to do your
homework:
a. readd my name (I didn't delete it, so I won't do the same job again, not
for sync reasons, and not for reasons of lack of time, and not for any other
reason.
b. fix orthographic errors in dvb-bt8xx.txt (for the same reason mentioned
in point a.)
c. reconstruct my 2.6.13-structure of dvb-bt8xx.txt as far as possible
d. reflect very well, whether debug parameters should not better be situated
in different documentation texts (logically structured, understandable)
Regards
Uwe Bugla
P. S.: akpm never complains about lack of time, and he is doing a very fair
and good job, and, at least for him, the amount of 54 patches is simply
peanuts. I love cooperation with guys like him!
In other words: I respect the demand that cvs-tree and current kernel must
be in sync somehow, but if the output is rubbish for several reasons and,
moreover, neglects my work, there is simply no reason for any kind of
respect. Because I ain't no idiot, just to say it in very simple words.
So please in future avoid to blame my person for things that you personally
don't get worked (synchronization or whatever kind).
And would you please answer me one question: How can I be shure that my
patchwork at least enters the institution akpm, if there is someone like you
in between complaining for lack of time and synchronization faults? I prefer
flat hierarchies (the real hidden success principle of Linux) and
cooperation with akpm works very fine.
So, as a matter of principle, I don't see any reason why I should prepare
and send in my work three, four, five times, just because at the other end
someone doesn't get his stuff synchronized or lacks time. I ain't no idiot!
Ya Basta!
And even if I would give in now for strategic reasons and do the same
fuckin' work again, how many Stezenbach clones or whoever would come up
afterwards and continue to fuck up my work in the same or just in a
different way you personally did? Who do you think you are and who do you
think I am? So please do your homework, and do it correct in the future, or
leave that job simply to another person. OK?
Any further questions, Mr. Johannes Stezenbach?
-- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen f?r GMX Partner: http://www.gmx.net/de/go/partner
On 5/4/07, Manu Abraham <[email protected]> wrote:
> Markus Rechberger wrote:
>
> > I mean the mail from Helge Hafting (thread [linux-dvb] Critical
> > points about kernel 2.6.21 and pseudo-authorities) at the very first
> > beginning.
> >
>
> I am replying to this mail, just because someone's spreading lies all
> around.
> On the mentioned thread, what i wrote (and that was the only mail from
> my side):
>
> There is a saying: "He who lives by the sword, dies by the sword."
>
And what issues are outstanding of these discussions? I went over it
and it just shows up that there have been communication problems in
2005.
We now have open issues with several device drivers and that's what we
should focus at.
Markus
-------- Original-Nachricht --------
Datum: Fri, 4 May 2007 00:06:51 +0200
Von: "Markus Rechberger" <[email protected]>
An: "Manu Abraham" <[email protected]>
CC: [email protected], [email protected]
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
> On 5/3/07, Manu Abraham <[email protected]> wrote:
> > Markus Rechberger wrote:
> > > On 5/3/07, Manu Abraham <[email protected]> wrote:
> > >> Mauro Carvalho Chehab wrote:
> > >> > Enough. Let's stop arguing non technical issues.
> > >> >
> > >> > If either one of you have any technical argue against the Trent's
> > >> > patches, please point where the fix is wrong. Otherwise, if you
> wish,
> > >> > you may send an acked-by agreeing with the fix.
> > >> >
> > >>
> > >> Why don't you stop this childish behaviour ?
> > >>
> > >> After explaining to you the reasons in the previous mail:
> > >> being the author and maintainer of dst/dst_ca and maintainer of
> > >> dvb-bt8xx, i NACK this change
> > >>
> > >> (1) You aren't DVB maintainer
> > >
> > > I've seen that too often already, now we could point to a mail someone
> > > sent to Uwe regarding maintainership.
> >
> >
> > FYI, I have never written to Uwe regarding any sort of maintainership.
> > You seem to be quite up with an overdose of drugs
> >
>
> I mean the mail from Helge Hafting (thread [linux-dvb] Critical
> points about kernel 2.6.21 and pseudo-authorities) at the very first
> beginning.
>
> > From 2005/09/13 - 2007/05/03 (till date) there have been 15 mails from
> > my side to Uwe, none of which has a topic whatsoever you say. Only the
> > first mail was a private mail and that is CC'd to Johannes as well.
> >
> > Firstly you seem to play politics by getting Uwe to flame me, then when
> > it backfired, you are trying to play tricks with the rest of the
> > community as well, by spreading nonsense statements.
> >
>
> I sent several comments to Uwe to stop flaming, Trent was in the CC
> sometimes I never wrote that he should flame on anyone.
> I can simply forward you all mails I sent to Uwe there's not one bad mail.
>
> My point is moreover to get that issue sorted out by either accepting
> his "proposal" or stating out why not to add it (and there must be a
> reason behind it, and no mail which is 2 years old, or explaining what
> the device is, again it got explained what's required from you)
>
> seems like your response is based on that misunderstood sentence,
> sorry for not beeing clear enough.
>
> Markus
Hi Markus, fine chap,
Please cool down...
I guess I understood Manu's response:
a. He just changed his priorities to pick up an old project that seemed to have died, but did not die at all - this project is called cx878 project, and it is the most radical approach that I ever have seen - trying to make all BT8xx drivers independent from bttv, which is not horrible, but only consequent, necessary, and good and fine.
Please see my previous mails on that issue.
Just read the ML to get the appropriate link and please get yourself in it to help developping it. I swear it is the right path, although I am still missing the avoidance of dvb-pll.c. A closer look into that module will quite easily tell you
that there aren't any BT8xx based PCI cards needing that module except the ones needing the lgdt330x frontend driver, which is maintained by Mike Krufky. So for all other cards treated by the dvb-bt8xx backend this module is nothing but heavily obsolete and nonsense, if not to say: RAM-Wasting.
b. In so far, Manu's statements do not base on any mail that is 2 years old, but he simply changed his mind, after it was necessarily me personally to build up "the golden bridge" for him, Mike and others as well.
c. I am deeply thankful for your diplomatic behaviour involving Trent, as this brought up Manu to react in the end instead of crawling back into his snail house.
d. But please let us establish peace among each other now, because without peace we will not be able to continue the whole thing...
Hi Trent,
I want to thank you for all your efforts - as they at least work for my deep satisfaction, but they may not work for other people as well for simply technical reasons (example: treating dst and dst_ca as one simple case does no good at all, does it?), but our primadonna Manuel Abraham simply follows another far more radical path - to get the whole thing independent from bttv, which is the RIGHT path.
Your invested energies weren't wasted at all, but they only approach "plan a" while "plan b" goes much more further than "plan a." It is as simple as that.
And, as I stated already, I am open for both plans - and if the more radical one gains more mercy I will not disagree, but simply follow it and trying my best to improve it.
Hi Mauro,
I would deeply appreciate you to pull my "proposal" for the Kconfig in the frontends section as at least the semantic problem gotta be resolved (SPO instead of SO - whoever wrote this). The question what card needs dvb-pll.c does not stay open so far - I just involved some fact about what card does really need it and what card simply never did.
However, also in "plan a" as in "plan b" the dvb-pll.c dependency issue stays open and I would deeply appreciate Mike Krufky to prepare a fix for us all.
It cannot be sufficient at all to be forced to compile a dvb-pll.c module for the whole group of bt8xx PCI cards if there is only one card that needs it being maintained by Mike, can it?
Again I state: The only bt8xx PCI based card that needs it is the one using the lgdt330x frontend driver - for all other cards of the BT8xx PCI kind that module is simply completely obsolete, if not to say: RAM-wasting nonsense.
And please stop to kill my deeply correct criticism with words like: "99 % of all cards need this module" or something like that, like you did in the past.
And please stop to kill my invested energies with sentences like "Again I say, please do not pull Uwe's patches at all, as he is only regarding things through his personal prisma."
Above from the fact that this is not really true it simply hurts and brings down all my invested energies for no acceptable reason.
In so far, you are NOT a neutral maintainer, like Markus stated, but you simply act playing unreasonable politics on me without knowing what you do.
Just be a little bit more open for the exception handling, even if you do not like to be. What I say is FACT, so please do not simply ignore the facts.
And after all I deeply respect that you are trying to be utmost restrictive as far as kernel oopses and regressions are concerned - I guess you're really doing fine as a team leader, although you are NOT neutral at least sometimes.
Hi Manuel,
I would deeply wish you to avoid the following words:
a. rant
b. childish behaviour
c. You aren't DVB maintainer
d. You seem to be quite up with an overdose of drugs
and other words like that.
Just to give you a very humble help:
Although Johannes stated that you were nothing but nerving when you were beginning this whole thing he himself tried to be always warm and encouraging to you.
So where is the reason in you personally that you cannot give back that positive behaviour please?
BTW:
I am really working hard on that cx878 project after the mercurial tree has been proven to work fine, and I hope that I can bring out some test report in order to make its development continue...
Yours sincerely
Uwe
>
> _______________________________________________
> linux-dvb mailing list
> [email protected]
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
Am Freitag, den 04.05.2007, 02:31 +0400 schrieb Manu Abraham:
> Markus Rechberger wrote:
>
> > I mean the mail from Helge Hafting (thread [linux-dvb] Critical
> > points about kernel 2.6.21 and pseudo-authorities) at the very first
> > beginning.
> >
>
> I am replying to this mail, just because someone's spreading lies all
> around.
> On the mentioned thread, what i wrote (and that was the only mail from
> my side):
>
> There is a saying: "He who lives by the sword, dies by the sword."
>
Within the last six years there was in the end exactly one, never asked
for, private mail with worst *bullshit* about another person, Mauro in
this case.
It came from you, out of any feasible arguments for me anymore.
I'm stupid, but not stupid enough to allow such stuff coming in rule.
But I still say you have been first and are waiting longest to get your
work in, please try again to get your ACKs and rant about not enough
replies.
Cheers,
Hermann
-------- Original-Nachricht --------
Datum: Fri, 04 May 2007 02:31:49 +0400
Von: Manu Abraham <[email protected]>
An: [email protected]
CC: [email protected]
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
> Markus Rechberger wrote:
>
> > I mean the mail from Helge Hafting (thread [linux-dvb] Critical
> > points about kernel 2.6.21 and pseudo-authorities) at the very first
> > beginning.
> >
>
> I am replying to this mail, just because someone's spreading lies all
> around.
> On the mentioned thread, what i wrote (and that was the only mail from
> my side):
>
> There is a saying: "He who lives by the sword, dies by the sword."
Hi Manu,
The saying that you stated is a very christian one.
I perhaps should state that I am 47 years old now, raised in in utmost reactionary region called Bavaria (Western Germany), and also raised by parents of Russian / Polonian origin who shared the Nazi regime with the usual "I-do-not-want-to-talk-about-it-and-I-do-not-want-to-feel-responsible-about-it "-behaviour.
And I am very much not only interested in german post-war history, but I simply love to write provocative letters or mails to make my conviction utmost clear that all this capitalist bullshit around us should vanish and shrink and be overcome some day.
Basic christian ideals are very close to basic marxist ideas.
The one who never does perceive that is a real poor human being in my eyes, if not to say: a complete idiot or a system-conforming hypocrite.
BUT:
I in fact do not read this "saying" for the first time:
In my personal experience (feel very sorry about it, but it's true) it has always truthfully been an excuse for persons being strongly limited on what I would call utmost primitive instincts like greed or rapacity (i. e. the utmost perfect sounding "would-like-to-capitalists", if not to say: the perfect slaves or: the perfect counterrevolutionaries or strike-breakers, if not to say: the utmost perfect asscreepers).
Please forgive me for that statement, but I am simply stating my personal experiences very truthfully, without playing any politics, but just telling you my "personal truth" or the sum of all my personal life experience unfortunately bound to that.
And if there is discussion needed on that we should do it private or anyway on some other thread, but definitely not on this one.
Hints to help you to understand the difference:
1. There is a GPL license written by Richard Stallman whose origin I do not know:
Its essence is the philosophy to share and to be highly transparent as far as information level is concerned.
2. There is a saying by Linus in which he states the best choice he ever did was conforming his work to the terms of Richard Stallman, the GPL.
3. Wikipedia says that Linus's father was no christian at all, but simply a communist.
See, Manu, there are deeply primitive instinct-driven hypocrites around like hell, but there are also truthful human beings around.
But:
The Internet does not provide a platform to find out who is who and what is what.
The Internet may be necessary, but in the end it's just a drag, isn't it?
Sincerely
Uwe
>
>
> -------- Original Message --------
> Subject: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and
> pseudo-authorities
> Date: Tue, 01 May 2007 04:19:41 +0400
> From: Manu Abraham <[email protected]>
> To: Uwe Bugla <[email protected]>
> CC: [email protected], [email protected],
> [email protected], [email protected],
> [email protected], [email protected]
> References: <[email protected]>
> <[email protected]>
> <[email protected]>
> <[email protected]>
> <[email protected]> <1177894713.3046.5.camel@p
> <[email protected]>
> <[email protected]>
> <[email protected]> <[email protected]>
>
> Uwe Bugla wrote:
>
> > 1. You utmost personally are responsible for 4 ununsable kernels, as
> far as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16!
> > 2. You did not even want to imply to resolve that issue by incarnating
> that "community and synergy principle" that linux community needs to
> exist at all, but you just perverted it by flaming capable people -
>
> You mean like this:
>
>
> -------- Original Message --------
> Subject: kernel patch practice in 2.6.13-mm2
> Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST)
> From: Uwe Bugla <[email protected]>
> To: [email protected]
> CC: [email protected]
>
> Hi,
> if you continue to send or sign mm-patches for Kernel 2.6.13 as a
> consequence of a design change I would appreciate you to stop rubbing out
> my
> name.
> You did that in a file called /Documentation/dvb/bt8xx.txt.
> My objective is understandable good documentation, even if it may sound
> trivial for some developpers minds. I always have in mind that there are
> also lots of beginners reading those documents.
> As I respect your work I never in my life would even dare to rub out other
> coauthors names.
> That?s why I appreciate you to respect my name and stop rubbing it out.
>
> Thanks
> Uwe Bugla
>
> P. S.: If you f. ex. publish a book I ain?t gonna burn it as a matter of
> disrespect. So have a little respect vice versa!
>
> --
> Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
> Satte Provisionen f?r GMX Partner: http://www.gmx.net/de/go/partner
>
>
> ------- Original Message --------
> Subject: "synchronization problems"
> Date: Thu, 15 Sep 2005 10:44:38 +0200 (MEST)
> From: Uwe Bugla <[email protected]>
> To: [email protected]
> CC: [email protected]
>
> Hallo Mr. Stezenbach,
>
> "You breached the protocol by not sending the patches to the maintainer
> or linux-dvb list. The result of this was that we had conflicting
> changes in CVS. I spent about 10 minutes thinking how I could
> merge the two, and then gave up (I had 53 other patches to prepare
> and I had little time left to do the job). So I didn't just remove
> your name, but all changes which you sent to akpm along with it.
> bt8xx.txt in the kernel is now in sync with the version in linuxtv.org
> CVS."
>
> I didn't breach any protocol, nor did I break any unwritten rule or law. I
> simply took the advice from Gerd Knorr that linuxtv maintainers were just
> moving to another place to the point of time when I sent in my first
> dvb-bt8xx-patch. So consequently I took the direct way to send it to akpm.
> Just to be sure it is really being applied without waiting 3, 4 weeks or
> however long. So if you continue to at least discussing with my person,
> please immediately stop doing that in such a bureaucratic manner. If
> synchronization of CVS and kernel.org only works unidirectional, and not
> bidirectional, then neither I, nor akpm, nor Manu or anybody else has a
> real
> problem, but you personally have one without any doubts.
> And if you lack time, simply delegate your job to another person. But
> simply
> stop rubbing out other peoples coauthorship and pay respect to their
> contributions. And the biggest joke about your personal misbehaviour is
> the
> fact that you personally cosigned at least one of my patch attempts,
> without
> dropping me a single note asking me to not bypass the linuxtv CVS
> maintainers. So good morning Mr. Stezenbach, I appreciate you to wake up a
> little bit earlier in the future!
>
> "Additionally you deleted information from bt8xx.txt which I think were
> useful help for debugging problems, and which were written there on
> purpose
> by the developer. So if you talk about respect, you could show some
> yourself
> by not bypassing the original authors and maintainers when sending
> patches."
>
> In fact I did, and I can tell you the simple reasons why.
> There are in fact two things that I simply cannot and will not tolerate:
> a. orthographic junk (examples: "bythe" or, even worse: "autodected" and
> "Recognise") It was ME who corrected that in the past, and it was YOU
> personally who reversed that, if not to say: fucked it up in the current
> 2.6.14-rc1. So as a consequence it is YOUR task to do your homework and
> apologize for that, but not MINE!
> b. attempts of documentation that do NOT correspond to their appropriate
> kernel design
> What do I mean with b.?
> 1. In Kernels 2.6.12 AND 2.6.13 the simple command "modprobe dvb-bt8xx"
> caused ALL OTHER modules to load automatically:
> cx24110, dst, dst-ci and dst-ca. Now if the kernel design forces the
> automatic loading of dst, dst-ca and dst-ci, every attempt of discussion
> about debug parameters is simply obsolete! So if I cannot load the dst
> module separately, how should I be able to hack in
> debug parameters? I know what debug parameters are for, and I deeply
> respect
> developers work, but what the hell is it all worth for if a kernel design
> suppresses hacking in debug parameters?
> 2. Moreover I am not shure in how far the parameters 0x68 and 0x71 really
> correspond to TwinHan cards. A closer look to CARDLIST.bttv says: card ID
> =
> 113. But perhaps I have problems to deal with hexadecimal numbers, and
> this
> would simply be my problem, not yours!
>
> 4 rules for a real good documentation:
> 1. understandable and transparent information for different understanding
> levels
> 2. strictly corresponding to the laws of the current kernel design
> 3. absolutely errorfree concerning orthographic junk
> 4. structured in a senseful manner (f. ex.: headliner corresponds to real
> contents)
>
> If an attempt of documentation lacks at least one of the four, it is
> simply
> useless to my opinion. Why aren't debug parameters part of another part of
> documentation, f. ex. ci.txt? Or ca.txt? The headline of dvb-bt8xx.txt
> goes:
> "How to get the Nebula, PCTV, and TwinHan DST cards working."
> My question: If the essence of a documentation text is how to bring up a
> specified card, then please what the hell has that got to do with debug
> parameters? Who are the addressed groups of such a text? To my opinion at
> least the headliner says that the following text addresses users and
> nobody
> else!
> So I simply never intended to bypass any developer, but I simply found out
> that the bt8xx-documentation simply did not correspond to the actual
> kernel
> design. In other words: Was unusable. So I decided to write a patch and
> simply act instead of performing endless discussions, and that's all about
> it!
> And: If you reinvent the name of cards: Do it for whatever reason, for
> god's
> sake! But: How the hell do you define to a person not convenient with all
> that special technical vocabulary, what the hell a BT8xx-card is? Remember
> the first of my 4 rules (see above!). So at least a complete list of cards
> conforming to that standard is necessary for transparent information:
> Question: Pinnacle PCTV SAT, Nebula Electronics DigiTV, TwinHan DST and
> clones, Avermedia of all kinds..... Is that list complete? If not, please
> drop me a note where I can get that complete list of cards corresponding
> to
> that standard, and I'll instantly sit down and write a patch to improve
> documentation.
> But before I even think about doing that I appreciate you to do your
> homework:
> a. readd my name (I didn't delete it, so I won't do the same job again,
> not
> for sync reasons, and not for reasons of lack of time, and not for any
> other
> reason.
> b. fix orthographic errors in dvb-bt8xx.txt (for the same reason mentioned
> in point a.)
> c. reconstruct my 2.6.13-structure of dvb-bt8xx.txt as far as possible
> d. reflect very well, whether debug parameters should not better be
> situated
> in different documentation texts (logically structured, understandable)
>
> Regards
>
> Uwe Bugla
>
> P. S.: akpm never complains about lack of time, and he is doing a very
> fair
> and good job, and, at least for him, the amount of 54 patches is simply
> peanuts. I love cooperation with guys like him!
> In other words: I respect the demand that cvs-tree and current kernel must
> be in sync somehow, but if the output is rubbish for several reasons and,
> moreover, neglects my work, there is simply no reason for any kind of
> respect. Because I ain't no idiot, just to say it in very simple words.
> So please in future avoid to blame my person for things that you
> personally
> don't get worked (synchronization or whatever kind).
> And would you please answer me one question: How can I be shure that my
> patchwork at least enters the institution akpm, if there is someone like
> you
> in between complaining for lack of time and synchronization faults? I
> prefer
> flat hierarchies (the real hidden success principle of Linux) and
> cooperation with akpm works very fine.
> So, as a matter of principle, I don't see any reason why I should prepare
> and send in my work three, four, five times, just because at the other end
> someone doesn't get his stuff synchronized or lacks time. I ain't no
> idiot!
> Ya Basta!
> And even if I would give in now for strategic reasons and do the same
> fuckin' work again, how many Stezenbach clones or whoever would come up
> afterwards and continue to fuck up my work in the same or just in a
> different way you personally did? Who do you think you are and who do you
> think I am? So please do your homework, and do it correct in the future,
> or
> leave that job simply to another person. OK?
> Any further questions, Mr. Johannes Stezenbach?
>
> --
> Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
> Satte Provisionen f?r GMX Partner: http://www.gmx.net/de/go/partner
>
> Hallo Mr. Stezenbach,
>
> "You breached the protocol by not sending the patches to the maintainer
> or linux-dvb list. The result of this was that we had conflicting
> changes in CVS. I spent about 10 minutes thinking how I could
> merge the two, and then gave up (I had 53 other patches to prepare
> and I had little time left to do the job). So I didn't just remove
> your name, but all changes which you sent to akpm along with it.
> bt8xx.txt in the kernel is now in sync with the version in linuxtv.org
> CVS."
>
> I didn't breach any protocol, nor did I break any unwritten rule or law. I
> simply took the advice from Gerd Knorr that linuxtv maintainers were just
> moving to another place to the point of time when I sent in my first
> dvb-bt8xx-patch. So consequently I took the direct way to send it to akpm.
> Just to be sure it is really being applied without waiting 3, 4 weeks or
> however long. So if you continue to at least discussing with my person,
> please immediately stop doing that in such a bureaucratic manner. If
> synchronization of CVS and kernel.org only works unidirectional, and not
> bidirectional, then neither I, nor akpm, nor Manu or anybody else has a
> real
> problem, but you personally have one without any doubts.
> And if you lack time, simply delegate your job to another person. But
> simply
> stop rubbing out other peoples coauthorship and pay respect to their
> contributions. And the biggest joke about your personal misbehaviour is
> the
> fact that you personally cosigned at least one of my patch attempts,
> without
> dropping me a single note asking me to not bypass the linuxtv CVS
> maintainers. So good morning Mr. Stezenbach, I appreciate you to wake up a
> little bit earlier in the future!
>
> "Additionally you deleted information from bt8xx.txt which I think were
> useful help for debugging problems, and which were written there on
> purpose
> by the developer. So if you talk about respect, you could show some
> yourself
> by not bypassing the original authors and maintainers when sending
> patches."
>
> In fact I did, and I can tell you the simple reasons why.
> There are in fact two things that I simply cannot and will not tolerate:
> a. orthographic junk (examples: "bythe" or, even worse: "autodected" and
> "Recognise") It was ME who corrected that in the past, and it was YOU
> personally who reversed that, if not to say: fucked it up in the current
> 2.6.14-rc1. So as a consequence it is YOUR task to do your homework and
> apologize for that, but not MINE!
> b. attempts of documentation that do NOT correspond to their appropriate
> kernel design
> What do I mean with b.?
> 1. In Kernels 2.6.12 AND 2.6.13 the simple command "modprobe dvb-bt8xx"
> caused ALL OTHER modules to load automatically:
> cx24110, dst, dst-ci and dst-ca. Now if the kernel design forces the
> automatic loading of dst, dst-ca and dst-ci, every attempt of discussion
> about debug parameters is simply obsolete! So if I cannot load the dst
> module separately, how should I be able to hack in
> debug parameters? I know what debug parameters are for, and I deeply
> respect
> developers work, but what the hell is it all worth for if a kernel design
> suppresses hacking in debug parameters?
> 2. Moreover I am not shure in how far the parameters 0x68 and 0x71 really
> correspond to TwinHan cards. A closer look to CARDLIST.bttv says: card ID
> =
> 113. But perhaps I have problems to deal with hexadecimal numbers, and
> this
> would simply be my problem, not yours!
>
> 4 rules for a real good documentation:
> 1. understandable and transparent information for different understanding
> levels
> 2. strictly corresponding to the laws of the current kernel design
> 3. absolutely errorfree concerning orthographic junk
> 4. structured in a senseful manner (f. ex.: headliner corresponds to real
> contents)
>
> If an attempt of documentation lacks at least one of the four, it is
> simply
> useless to my opinion. Why aren't debug parameters part of another part of
> documentation, f. ex. ci.txt? Or ca.txt? The headline of dvb-bt8xx.txt
> goes:
> "How to get the Nebula, PCTV, and TwinHan DST cards working."
> My question: If the essence of a documentation text is how to bring up a
> specified card, then please what the hell has that got to do with debug
> parameters? Who are the addressed groups of such a text? To my opinion at
> least the headliner says that the following text addresses users and
> nobody
> else!
> So I simply never intended to bypass any developer, but I simply found out
> that the bt8xx-documentation simply did not correspond to the actual
> kernel
> design. In other words: Was unusable. So I decided to write a patch and
> simply act instead of performing endless discussions, and that's all about
> it!
> And: If you reinvent the name of cards: Do it for whatever reason, for
> god's
> sake! But: How the hell do you define to a person not convenient with all
> that special technical vocabulary, what the hell a BT8xx-card is? Remember
> the first of my 4 rules (see above!). So at least a complete list of cards
> conforming to that standard is necessary for transparent information:
> Question: Pinnacle PCTV SAT, Nebula Electronics DigiTV, TwinHan DST and
> clones, Avermedia of all kinds..... Is that list complete? If not, please
> drop me a note where I can get that complete list of cards corresponding
> to
> that standard, and I'll instantly sit down and write a patch to improve
> documentation.
> But before I even think about doing that I appreciate you to do your
> homework:
> a. readd my name (I didn't delete it, so I won't do the same job again,
> not
> for sync reasons, and not for reasons of lack of time, and not for any
> other
> reason.
> b. fix orthographic errors in dvb-bt8xx.txt (for the same reason mentioned
> in point a.)
> c. reconstruct my 2.6.13-structure of dvb-bt8xx.txt as far as possible
> d. reflect very well, whether debug parameters should not better be
> situated
> in different documentation texts (logically structured, understandable)
>
> Regards
>
> Uwe Bugla
>
> P. S.: akpm never complains about lack of time, and he is doing a very
> fair
> and good job, and, at least for him, the amount of 54 patches is simply
> peanuts. I love cooperation with guys like him!
> In other words: I respect the demand that cvs-tree and current kernel must
> be in sync somehow, but if the output is rubbish for several reasons and,
> moreover, neglects my work, there is simply no reason for any kind of
> respect. Because I ain't no idiot, just to say it in very simple words.
> So please in future avoid to blame my person for things that you
> personally
> don't get worked (synchronization or whatever kind).
> And would you please answer me one question: How can I be shure that my
> patchwork at least enters the institution akpm, if there is someone like
> you
> in between complaining for lack of time and synchronization faults? I
> prefer
> flat hierarchies (the real hidden success principle of Linux) and
> cooperation with akpm works very fine.
> So, as a matter of principle, I don't see any reason why I should prepare
> and send in my work three, four, five times, just because at the other end
> someone doesn't get his stuff synchronized or lacks time. I ain't no
> idiot!
> Ya Basta!
> And even if I would give in now for strategic reasons and do the same
> fuckin' work again, how many Stezenbach clones or whoever would come up
> afterwards and continue to fuck up my work in the same or just in a
> different way you personally did? Who do you think you are and who do you
> think I am? So please do your homework, and do it correct in the future,
> or
> leave that job simply to another person. OK?
> Any further questions, Mr. Johannes Stezenbach?
>
> -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
> Satte Provisionen f?r GMX Partner: http://www.gmx.net/de/go/partner
>
> _______________________________________________
> linux-dvb mailing list
> [email protected]
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
Hi Manu,
Em Qui, 2007-05-03 às 23:03 +0400, Manu Abraham escreveu:
> Mauro Carvalho Chehab wrote:
> > Enough. Let's stop arguing non technical issues.
> >
> > If either one of you have any technical argue against the Trent's
> > patches, please point where the fix is wrong. Otherwise, if you wish,
> > you may send an acked-by agreeing with the fix.
> >
>
> Why don't you stop this childish behaviour ?
I just want to solve the current issue, and decide the proper way for Trent's fixes.
I consider you a very skilled programmer. Unfortunately, it seems that
you're not interested anymore on submitting kernel patches, since your
last contribution, as an author, were back on Aug, 8, 2006:
commit bbdd11fa957913d6648cabbca59be1da479180ed
Author: Manu Abraham <[email protected]>
Date: Tue Aug 8 15:48:08 2006 -0300
V4L/DVB (4432): Fix Circular dependencies
Signed-off-by: Manu Abraham <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
It would be a pleasure to have you contributing again. However, we need to fix the pointed issues.
Also, considering that:
1) the Trent patches addressing the issues exists since august, 2006;
2) nobody pointed any troubles at the current approach;
3) the patch does provide a proper fix for module removal, working well on both hardwares with and without DST;
4) I'm responsible for reviewing and forwarding patches for /drivers/media stuff;
I think there's no reason for me to not forward the proper fixes to mainstream.
--
Cheers,
Mauro
Hello Mauro,
Mauro Carvalho Chehab wrote:
> Hi Manu,
>
> Em Qui, 2007-05-03 às 23:03 +0400, Manu Abraham escreveu:
>> Mauro Carvalho Chehab wrote:
>>> Enough. Let's stop arguing non technical issues.
>>>
>>> If either one of you have any technical argue against the Trent's
>>> patches, please point where the fix is wrong. Otherwise, if you wish,
>>> you may send an acked-by agreeing with the fix.
>>>
>> Why don't you stop this childish behaviour ?
>
> I just want to solve the current issue, and decide the proper way for Trent's fixes.
>
> I consider you a very skilled programmer. Unfortunately, it seems that
> you're not interested anymore on submitting kernel patches, since your
> last contribution, as an author, were back on Aug, 8, 2006:
hmm .. multiple Caps "I 's" .. anyway.
>From my side, quite some time has been put forward to write that mail.
Inspite of that if you feel that you do have to go your own way, then it
is completely upto you. I would say: do as you feel in such a case.
In such a case are you willing to fix all the issues/requests that surface ?
Really do you want me to explain those issues in this thread ? I would
say, think over it yourself, why that huge gap occurred. Take some time
off all this, think on a cool mind.
>
> commit bbdd11fa957913d6648cabbca59be1da479180ed
> Author: Manu Abraham <[email protected]>
> Date: Tue Aug 8 15:48:08 2006 -0300
>
> V4L/DVB (4432): Fix Circular dependencies
>
> Signed-off-by: Manu Abraham <[email protected]>
> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
>
> It would be a pleasure to have you contributing again. However, we need to fix the pointed issues.
I do have a written another mail with regards to the issues that do
prevail on the "discussions thread"
>
> Also, considering that:
>
> 1) the Trent patches addressing the issues exists since august, 2006;
>
> 2) nobody pointed any troubles at the current approach;
>
Surely there was a long mail from my side. I don't know whether you
missed that mail, but surely you should read it again.
> 3) the patch does provide a proper fix for module removal, working well on both hardwares with and without DST;
>
Other than what i wrote earlier:
DST is not for just one device alone (It is really a combo driver),
AFAICS there are ~15 -20 main devices, for which there are additional 5
- 6 clone manufacturers. So eventually there are around 80 different
cards at least.
So, in fact there are a large number of cards that do exist rather than
the one card that i have sent you, some time back.
The non dst cards supported by dvb-bt8xx are just 3 or 4 cards, IIRC.
> 4) I'm responsible for reviewing and forwarding patches for /drivers/media stuff;
>
> I think there's no reason for me to not forward the proper fixes to mainstream.
>
>From what i know, you do need an ACK from the relevant maintainer too.
Did the concept of dvb-maintainers change without any of the DVB
developers knowing ?
Hi Manu,
> From my side, quite some time has been put forward to write that mail.
> Inspite of that if you feel that you do have to go your own way, then
> it is completely upto you. I would say: do as you feel in such a case.
The point is that those issues are pending for a long time, and they
should be solved, especially the module removal issue (*)
If you are so afraid about applying those changes, maybe the better is
to apply those patches at v4l-dvb tree and at -mm, asking people to
test.
We may hold their commit on kernel mainstream until the next kernel
release, if nobody complains about, or otherwise revert the changes, if
they proofed to cause troubles at dst and/or dvb-bt8xx.
Also, you (or others) may write another approach keeping the fixes with
an strategy more adequate for dst.
Do you agree with this way?
--
Cheers,
Mauro
(*) Currently, dst can be removed only with "rmmod -f", due to a wrong
usage count. With Trent's patches, this were fixed.
Mauro Carvalho Chehab wrote:
> Hi Manu,
>
>> From my side, quite some time has been put forward to write that mail.
>> Inspite of that if you feel that you do have to go your own way, then
>> it is completely upto you. I would say: do as you feel in such a case.
>
> The point is that those issues are pending for a long time, and they
> should be solved, especially the module removal issue (*)
>
> If you are so afraid about applying those changes, maybe the better is
> to apply those patches at v4l-dvb tree and at -mm, asking people to
> test.
>
> We may hold their commit on kernel mainstream until the next kernel
> release, if nobody complains about, or otherwise revert the changes, if
> they proofed to cause troubles at dst and/or dvb-bt8xx.
>
> Also, you (or others) may write another approach keeping the fixes with
> an strategy more adequate for dst.
>
> Do you agree with this way?
NACK
>
> --
> Cheers,
> Mauro
>
> (*) Currently, dst can be removed only with "rmmod -f", due to a wrong
> usage count. With Trent's patches, this were fixed.
http://article.gmane.org/gmane.linux.drivers.dvb/27792/match=re+linux+dvb+unable+rmmod+dst+bt8xx
Manu Abraham wrote:
> Mauro Carvalho Chehab wrote:
>> Hi Manu,
>>
>>> From my side, quite some time has been put forward to write that mail.
>>> Inspite of that if you feel that you do have to go your own way, then
>>> it is completely upto you. I would say: do as you feel in such a case.
>> The point is that those issues are pending for a long time, and they
>> should be solved, especially the module removal issue (*)
>>
>> If you are so afraid about applying those changes, maybe the better is
>> to apply those patches at v4l-dvb tree and at -mm, asking people to
>> test.
>>
>> We may hold their commit on kernel mainstream until the next kernel
>> release, if nobody complains about, or otherwise revert the changes, if
>> they proofed to cause troubles at dst and/or dvb-bt8xx.
>>
>> Also, you (or others) may write another approach keeping the fixes with
>> an strategy more adequate for dst.
>>
>> Do you agree with this way?
>
> NACK
>
>> --
>> Cheers,
>> Mauro
>>
>> (*) Currently, dst can be removed only with "rmmod -f", due to a wrong
>> usage count. With Trent's patches, this were fixed.
>
> http://article.gmane.org/gmane.linux.drivers.dvb/27792/match=re+linux+dvb+unable+rmmod+dst+bt8xx
Just to make things clear, Manu, Are you telling us that the patch in the above
link addresses the use count bug?
If that is the case, are you suggesting that that patch be applied to the
repository instead of Trent's changesets?
Moreso, if that is the case, then the patch in the above link lacks a
sign-off... We need to apply SOMETHING to fix this problem, and you know the
rules...
What should be done to fix the use count bug?
Regards,
Michael Krufky
Michael Krufky wrote:
> Manu Abraham wrote:
>> Mauro Carvalho Chehab wrote:
>>> Hi Manu,
>>>
>>>> From my side, quite some time has been put forward to write that mail.
>>>> Inspite of that if you feel that you do have to go your own way, then
>>>> it is completely upto you. I would say: do as you feel in such a case.
>>> The point is that those issues are pending for a long time, and they
>>> should be solved, especially the module removal issue (*)
>>>
>>> If you are so afraid about applying those changes, maybe the better is
>>> to apply those patches at v4l-dvb tree and at -mm, asking people to
>>> test.
>>>
>>> We may hold their commit on kernel mainstream until the next kernel
>>> release, if nobody complains about, or otherwise revert the changes, if
>>> they proofed to cause troubles at dst and/or dvb-bt8xx.
>>>
>>> Also, you (or others) may write another approach keeping the fixes with
>>> an strategy more adequate for dst.
>>>
>>> Do you agree with this way?
>> NACK
>>
>>> --
>>> Cheers,
>>> Mauro
>>>
>>> (*) Currently, dst can be removed only with "rmmod -f", due to a wrong
>>> usage count. With Trent's patches, this were fixed.
>> http://article.gmane.org/gmane.linux.drivers.dvb/27792/match=re+linux+dvb+unable+rmmod+dst+bt8xx
>
> Just to make things clear, Manu, Are you telling us that the patch in the above
> link addresses the use count bug?
>
Yes
> If that is the case, are you suggesting that that patch be applied to the
> repository instead of Trent's changesets?
>
Yes
> Moreso, if that is the case, then the patch in the above link lacks a
> sign-off... We need to apply SOMETHING to fix this problem, and you know the
> rules...
>
Signed-off-by: Manu Abraham <[email protected]>
> What should be done to fix the use count bug?
>
It does fix, AFAIR
Regards,
Manu
-------- Original-Nachricht --------
Datum: Mon, 07 May 2007 17:54:29 -0300
Von: Mauro Carvalho Chehab <[email protected]>
An: Manu Abraham <[email protected]>
CC: [email protected], [email protected]
Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
> Hi Manu,
>
> > From my side, quite some time has been put forward to write that mail.
> > Inspite of that if you feel that you do have to go your own way, then
> > it is completely upto you. I would say: do as you feel in such a case.
>
> The point is that those issues are pending for a long time, and they
> should be solved, especially the module removal issue (*)
>
> If you are so afraid about applying those changes, maybe the better is
> to apply those patches at v4l-dvb tree and at -mm, asking people to
> test.
>
> We may hold their commit on kernel mainstream until the next kernel
> release, if nobody complains about, or otherwise revert the changes, if
> they proofed to cause troubles at dst and/or dvb-bt8xx.
>
> Also, you (or others) may write another approach keeping the fixes with
> an strategy more adequate for dst.
>
> Do you agree with this way?
>
> --
> Cheers,
> Mauro
>
> (*) Currently, dst can be removed only with "rmmod -f", due to a wrong
> usage count. With Trent's patches, this were fixed.
Mauro,
First of all, Manu is not a machine shitting out solutions on other one's pressure.
And he is doing right so far, as far as what happened.
Second: You should do some self-reflection on the damage you did on the human layer.
You appear like not even having any intention or idea on how to do that, you just behave technocratic and cold, you are just doing "I-AM-THE-BOSS, AND-NOTHING-GOES-WITHOUT-ME"-politics, that's all.
Even if you do not have at least partially any idea about it all, you just try to rule "godlike", you know. Not everybody agrees with that ruling style, just a hint for you that you do not ever want to see, because you prefer to be blind in order to rule, to move on to the daily dayplan, as if nothing happened. But there happened many things. But you just prefer to be blind.
Currently me and Manu are working on a long lasting project very harmonizing, which I never believed to be possible at all, but we do work together :-).
And as long as the the ruler behaviour and the ruling structure of linuxtv.org keeps on behaving like this (including all the nasty people like mrechberger for instance), then let me tell you that I care a shit about what is being pulled into the kernel and what is not, man!
Now if you cannot take that I feel sorry, but he whole system around here gotta be changed as far as maintainership is concerned.
You cannot go on like this, Mr. Chehab, and even if you keep on ignoring this message you will be producing nothing but damage in the end.
Noone was born to act and behave like a nodding nigger in front of you - and if you do not want to take that, well, then you're strictly obsolete, man!
Without any politeness
Uwe
>
>
> _______________________________________________
> linux-dvb mailing list
> [email protected]
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail