Adrian, do you really believe that the above is substantial ?
You spotted a bug, decoded a bug report and fixed a Kconfig. Nobody
says that this is a bad contribution, but it does not qualify you at
all to act as the uber controller of the kernel.
I always defended your contributions, which were questioned by a lot
of kernel developers, but your recent attitude of artificially
inflating bugs, which are either already resolved, have patches
pending or are actively worked on is annoying a lot of kernel folks,
not only Peter.
I'm sure Peter would have accepted such a patch, if there was a good
technical reason for it.
Your book-keeper list of bugreports lacks technical insight and is not
a good technical reason, it's just a strawman to gain control and/or
importance.
The bugzilla lists are good to remind us about outstanding problems,
but they are in no way the sole technical measure for marking a
functionality broken. Bugzilla is a tracking tool, nothing else. Using
it as a technical measure is just like the management illusion that
you can control a company with spread-sheets.
Following your book-keeper logic we have to mark HIBERNATE, SUSPEND,
NOHZ, HIGHRES, TSC and tons of other things BROKEN as well.
Marking it BROKEN is the last resort when we have something unfixable
which causes data corruption or crashes for which there is no active
maintainer who's willing to stand up for breakage.
Marking an incomplete default off feature, which does not result in
crashes or data corruption, BROKEN is just wrong. EXPERIMENTAL is the
correct category to get it exposed to users which helps to get
information about the side effects.
I enjoy working with Rafael on a technical level on those bugzilla
issues, but your vain attempt to influence the kernel development by
bureaucrazy will just lead to further ignorance vs. the kernel
bugzilla as the signal/noise ratio already reached an high annoyance
level since you started to abuse it for your renewed quality crusade.
Your previous attempt to control kernel development via the regression
list failed and you resigned. Now you come back and attack particular
subsystem developers/maintainers with the same method. Do you really
believe that abusing statistics for your exaggerated problem inflation
is solving any problems ?
No, it's causing more problems because you slander and frustrate
active developers who are aware of the issues and are working hard to
resolve them. The least thing they need is "motivation" in form of
such patches.
For what ? For telling the truth ?
Thanks,
tglx
--
