What's acceptable is purely subjective. Another good reason for a
post-distribution distribution. Many of us do it anyway, for
significant and useful functionality which hasn't found its way
through the `input filtering'.
Well, that's your (and each patch author's) choice. You can choose not
to submit it to Linus and through the kernel modification process, and
simply integrate the patch after each stable release. However, this
takes time, and effort, since the kernel is changing and improving.
The avoidance of this effort, plus the altruistic desire to get the
improvement used by a larger number of people, is what encourages people
to do the extra work to get the patch into the development kernel.
I think one of the things which you don't appreciate that a lot of what
the input filtering is for is to get rid of bogus patches. Sturgeon's
law of 99% of what's out there is crap really applies here. Yes, I'm
sure *you* think your particular patch you're championing is pure gold,
and everything else is pure dross --- but that's what everybody else
thinks, too.
If it weren't for the input filtering, we would end up with something
like NT/Windows 2000 --- a huge, bloated kernel, that blue screens
constantly.
> You can't get away from this. Why should Linus/Alan/other kernel patch
> hoovers have to merge an old patch without the help of its author?
That's not what's being suggested. The question posed was more like:
why are authors expected to operate with no feedback in generating
new patches.
If you wait until you have a huge monolithic patch, and then ask for
feedback, you're already too late. What you should do is post your
design to the linux-kernel list first, and solicit input. Once people
are generally agreed that you have a good design, *then* you implement
it, preferably in stages and with close contact with the maintainers of
the subsystems you are affecting (if your pet change requires touching
large number of other people's code).
If you post a design to the linux-kernel list, you will generally get
feedback.
I'll give you an example: GGI. Nobody seems to know quite what
happened to it. Not even people arguing on your side can articulate
the reasons clearly. That's reasonable evidence of non-transparency.
The original design had far too much functionality stuffed into the
kernel, and the folks trying to implement were told that. But instead
of working with folks, they were overly antagonistic, and as a result
they couldn't present their ideas well. Over time, their design
changed, and more stuff was moved out of the kernel compared to their
original design, but I never heard anyone say ("you were right, and
we've made the following changes in response to your constructive
criticism").
In the end, the fbcon patches did get accepted into the kernel, and
implemented a lot of what the kernel pieces of GGI was supposed to do.
The difference is that the fbcon people were willing to work within the
system, and the GGI folks weren't. Being an Angry Young Man thrusting
your fist into the air isn't going to impress many people in this
community.
The author of the piece of code I am interested in has no idea why
the code didn't get incorporated. That's not a transparent process.
If you're not willing to learn about the process, or work within the
system, I have news for you --- no system is transparent. There are
books written about the Linux kernel, there are FAQ's, there are web
pages. If you don't like any of them, you're free to write down and
document the process better. If you're not quite so arrogrant and
abrasive, people might even help you.
I asked a simple question in my initial post: `Is there a good
reason, or indeed any reason, why epckpt isn't in the kernel right
now?'
I think it's fairly simple. Both the author of epckpt and you don't
seem to have any clue about how the Linux kernel development process
works, and didn't submit it to the 2.3 kernel before the feature
freeze. New features aren't as a rule accepted into stable kernel
series. (That rule has been bent before, and usually it's universally
acknowledged that doing so was a serious mistake.)
Just as you can't blame the C language if you can't be bothered to learn
about C before writing a program which then is crap, you can't blame the
linux kernel development process if you can't be bothered to learn about
it before trying to get a patch submitted to it. And you certainly
won't get any sympathy if you can't be bothered to learn about it before
starting to flame about it.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/