* Adrian Bunk <bunk@kernel.org> wrote:NAK. The regressions you've listed should all be fixed by Peter and Mike in the current scheduler queue either via fixes or via reverts. Basically all the group scheduling ones revolve around a single technical issue: group-aware load-balancing which got touched in .26-rc1 and which is not fully cooked yet. You are distorting reality: there's not a single kernel crash/hang or app crash open in -rc4 and the fixes (or reverts) are all in the v2.6.26 scheduler pipeline and performance/scalability and interactivity is back to .25 levels or better. But more generally, beyond this specific incident that you generated, i can see a big problem in another area: lately you have visibly intensified your attempts to boss people around on lkml. Doing small janitorial fixes is fine (and useful), but you are now also actively wasting people's time, you are frequently showing an attitude, you are exaggerating bugs and you are interfering with the workflow of kernel developers. Furthermore, you've now also upset a MAJOR contributor (Peter Zijstra), and upsetting Peter is quite a feat i have to say. You do all that while the shocking reality is that you have no real experience and no real track record _at all_ in writing more complex kernel code yourself! How do you expect to be able to judge such issues without having the first-hand experience? To make sure i'm accurate about this i just spent 15 minutes reviewing all your past commits to the Linux kernel using "git-shortlog --author=Bunk", and the rather sobering truth appears to be that: - you've _never_ before fixed a complex Linux kernel bug/problem - you've never before written a _single_ Linux kernel feature - you've never before written a _single_ Linux driver - you've never before done any true self-driven functional changes/improvements to Linux What you did are 1500+ trivial commits that all revolve around the same janitorial topics: symbol fixes, trivial fixes (often gleaned off Coverity logs, sparse or namespacecheck output) and dead code removal. The method i used to review your past contributions was to first exclude the main body of your commits via this shell pattern: git-shortlog --author=Bunk | grep -viE "remov|static|build|license|\ extern|export|syntax|off by|overflow|cleanup|prototype|inline|select|\ bool|tristate|include|depend|init|section|config|scheduled|marked|#if|\ text|off-by-one|\.h|firmware|NULL|global|return|compare|leak|use-after|\ typo|dead|compil|delete|trivial|check after|spelling|small|update|\ check|kill|=|indent|tiny|deprecated|obsolete|endian|default|__dev|renam" this eliminated 94.8% of your 1607 commits of the past 3 years. I reviewed the remaining 83 commits manually, and they all, without exception, appeared trivial too. I also have direct experience with you as the maintainer of various subsystems: you never before approched me about any non-trivial technical issue about _anything_ in the kernel. So it appears to me - and all facts i have show it - that you appear to have no desire _at all_ to write true kernel code. You appear to have no ideas of your own (that you express publicly) and you appear to have no technical wishes or intellectual curiosity about Linux that rises beyond the level of trivialities. ... which might still all be fine and you could still be useful to Linux even if you are never able to rise above that trivial level, but the difference is that you also do appear to have a very strong desire to be seen as an "important person". Worse than that, you now have also decided to become a major obstacle in other people's workflow. And _that_ is a VERY big problem. You are quite delusive if you think people will tolerate that kind of behavior. I used to be a defender of your trivial commits in the past, because i'm strongly convinced that the path towards more complex code is through doing trivial changes. But you appear to be the exception that proves the rule: you stubbornly remained at the intellectual level of trivial commits. Adrian, the thing is, if you have the desire to become a maintainer, the very first basic step towards maintaining any kernel code is to start _writing_ kernel code, then you can maintain the code you wrote. Linux is not a project where you can get away without actually being able to write code. This total, 100% lack of substantial commits from you is OK as long as someone only has tangential (or initial) interest in Linux, but it is rather shocking from someone like you who has been around for years and who tries to be a force in kernel development. I dont really understand how you can think that this will fly with us. You also seem to have a track record of ... similar incidents and a crusade in another space - here is this 2002 mail from you on one of the Debian lists: http://lists.debian.org/debian-devel/2002/01/msg02160.html " I do hereby completely retire from Debian. [...] " You've recently asked on lkml whether you should quit kernel hacking too - and my answer is that you need to start kernel hacking before you can quit it. You are now on the path to become the equivalent of a self-important buerocrat who creates his own work and who plays petty office politics. Which is quite a feat i have to say, given the tons of real technical work that is still to be done in Linux. Ingo --
| Mike Galbraith | Re: regression: CD burning (k3b) went broke |
| Andi Kleen | [PATCH] [3/22] x86_64: Kill temp boot pmds |
| Alan Cox | Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...? |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
git: | |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 05/37] dccp: Cleanup routines for feature negotiation |
| Brandeburg, Jesse | RE: [PATCH] e1000e: test MSI interrupts |
