Messages in this thread | | | Date | Wed, 15 Sep 1999 08:40:26 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: Accountability |
| |
Date: Wed, 15 Sep 1999 21:52:52 +1000 From: Colin McCormack <colin@field.medicine.adelaide.edu.au>
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/
| |