From: Helge Hafting <helge.hafting@aitel.hist.no>
To: Uwe Bugla <uwe.bugla@gmx.de>
Cc: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org, mchehab@infradead.org
Subject: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Date: Mon, 30 Apr 2007 17:04:43 +0200 [thread overview]
Message-ID: <4636058B.3070603@aitel.hist.no> (raw)
In-Reply-To: <20070430115000.194060@gmx.net>
Uwe Bugla wrote:
> -------- Original-Nachricht --------
> Datum: Mon, 30 Apr 2007 13:21:29 +0200
> Von: Helge Hafting <helge.hafting@aitel.hist.no>
> An: Uwe Bugla <uwe.bugla@gmx.de>
> CC: linux-kernel@vger.kernel.org
> Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
>
>
>> Uwe Bugla wrote:
>>
>>> In this ten Emails you will yourself see the intellectual and technical
>>>
>> proof in how far Mr. Chehab is acting with nothing else but:
>>
>>> a. Lies
>>> b. Unproven thesis
>>> c. Stigmatizations
>>>
>>> and so on.
>>>
>>> THIS MAN HAS NO IDEA, BUT HE HAS THE POWER!
>>>
>>>
>> Please note that there are ways to replace a bad maintainer.
>> We still try to keep it polite.
>>
>> But note that you can't have someone "fired", no matter how bad they
>> do their job. A bad maintainer is usually better than none - the bad
>> maintainer might improve. Or at least get some simple stuff done.
>>
>> You therefore replace a bad maintainer by taking over the position.
>> Contact whoever is above the maintainer (Linus or some other
>> higher-level maintainer). You explain the problem, and you must also
>> show that you have the time and knowledge to do a better job.
>>
>
> Hi Helge,
> A. I do neither have enough skills to take up a maintainers role
>
Then your only hope is to find someone else that is interested.
> B. Linus and Andrew are high-leveled informed about the whole structural problem, but they close their eyes, they simply do not want to see the necessity of a replacement.
> That is at least my impression.
>
The aren't doing any less than you do. They don't provide a better
maintainer, but neither do you. Linus and Andrew don't have that
much more resources than you have. They have programming skills
and lots of trust in the community.
>> You can, for example, maintain the same subsystem in parallel. After a
>> while,
>> all interested parties sees that your tree works better and that
>> communicating with you is easier.
>> If you aren't prepared to do this - then you have to live with the current
>> maintainer. There is no staff ready to replace maintainers after
>> complaints, a volunteer doing a better job is always necessary.
>>
>
> Neither nor: I do not livbe with persons like Chehab and others, no matter what the consequence is. To be truthful I would strategically prefare a vacuum at the price that the work isn't even done for months.
> ONLY IF there is a personnel vacuum the necessity for others to volunteer will arise.
>
A sufficiently bad maintainer will also do it. If lots of submitters send
their patches to andrew in order to get past a dysfunctional maintainer,
then the subsystem effectively is unmaintained.
> So if you want a real change you gotta first kick the reactionary dumb bastards off from their seats without any return ticket - without that there won't be any changes at all!
>
Well then - create a patch to the MAINTAINERS file that removes this
maintainer
leaving the position open. Perhaps you can get that accepted despite the
existing maintainer - *if* you can get most other developers for that
subsystem to add signed-off lines. It will then be clear that the
community agrees with you.
However, if the bulk of them thinks the current maintainer is fine, then
it stays that way. Satisfying everybody is unfortunately not always
possible.
You can always try submitting your own patches above this maintainer.
> But the practice now is the typical "Sit out and do not react at all" behaviour as far as Chehab himself is concerned - Germans remember that reactionary gesture from the time when Hellmut Kohl was chancellor for 16 horrible years.....
>
> So there will be no "soft" or "polite" solution at all, but only a harsh and rude one:
> "Kick out the Jams!"
Dropping lazy or incompetent maintainers do happen occationally.
But don't let frustration lead to angry emails - all you get that way is
lost
credibility, that will only make it harder to convince people.
Helge Hafting
next prev parent reply other threads:[~2007-04-30 15:13 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-29 18:22 Critical points about kernel 2.6.21 and pseudo-authorities Uwe Bugla
2007-04-29 18:49 ` Linus Torvalds
2007-04-29 20:59 ` Uwe Bugla
2007-04-29 21:19 ` Linus Torvalds
2007-04-29 23:00 ` Uwe Bugla
2007-04-30 0:58 ` [linux-dvb] " hermann pitton
2007-04-30 11:02 ` Uwe Bugla
2007-04-30 11:21 ` Helge Hafting
2007-04-30 11:50 ` Uwe Bugla
2007-04-30 15:04 ` Helge Hafting [this message]
2007-04-30 15:24 ` Markus Rechberger
2007-04-30 16:09 ` Uwe Bugla
2007-04-30 16:56 ` Mauro Carvalho Chehab
2007-04-30 17:25 ` Uwe Bugla
2007-04-30 18:04 ` Linus Torvalds
2007-04-30 18:07 ` Uwe Bugla
2007-04-30 18:14 ` Andrew Morton
2007-04-30 18:29 ` Uwe Bugla
2007-04-30 18:29 ` Jan Engelhardt
2007-04-30 19:42 ` Markus Rechberger
2007-04-30 11:35 ` Thomas Gleixner
2007-04-30 11:48 ` Markus Rechberger
2007-04-30 12:37 ` Uwe Bugla
2007-04-30 13:06 ` Markus Rechberger
2007-04-30 14:09 ` Uwe Bugla
2007-04-30 15:30 ` Michael Krufky
2007-04-30 16:39 ` Uwe Bugla
2007-04-30 14:49 ` Linus Torvalds
2007-04-30 15:19 ` Uwe Bugla
2007-04-30 15:56 ` Linus Torvalds
2007-04-30 22:41 ` Trent Piepho
2007-04-30 22:58 ` Manu Abraham
2007-04-30 23:08 ` Markus Rechberger
2007-04-30 23:40 ` Uwe Bugla
2007-05-01 0:19 ` Manu Abraham
2007-05-01 0:29 ` Markus Rechberger
2007-05-01 9:23 ` Uwe Bugla
2007-04-30 23:05 ` Uwe Bugla
2007-04-30 23:20 ` hermann pitton
2007-04-30 1:37 ` Trent Piepho
2007-04-30 10:47 ` Uwe Bugla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4636058B.3070603@aitel.hist.no \
--to=helge.hafting@aitel.hist.no \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=uwe.bugla@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox