Archive for November, 2005
My friend Mark sent me this, suggesting that the principles apply to some of the things we do. He’s correct, but it extends further then that. It can be applied in lots of
When you submit a patch for acceptance, it will be reviewed on its technical merits and those alone.
So, what should you be expecting?
- criticism
- comments
- requests for change
- requests justification
- silence
What should you not do?
- expect your patch to be accepted without question
- become defensive
- ignore comments
- resubmit the patch without making any of the requested changes
Good things to say regarding your proposed changes:
- “This solves multiple problems.”
- “This deletes 2000 lines of code.”
- “Here is a patch that explains what I am trying to describe.”
- “I tested it on 5 different architectures…”
- “Here is a series of small patches that…”
- “This increases performance on typical machines…”
Bad things you should avoid saying:
- “We did it this way in AIX/ptx/Solaris, so therefore it must be
good…”
- “I’ve being doing this for 20 years, so…”
- “It makes this proprietary benchmark go faster”
- “This is required for my company to make money”
- “This is for our Enterprise product line.”
- “Here is my 1000 page design document that describes my idea”
- “I’ve been working on this for 6 months…”
- “Here’s a 5000 line patch that…”
- “I rewrote all of the current mess, and here it is…”
- “I have a deadline, and this patch needs to be applied now.”
The Linux kernel community does not gladly accept large chunks of code dropped on it all at once. The changes need to be properly introduced, discussed, and broken up into tiny, individual portions. This is almost the exact opposite of what companies are used to doing. Your proposal should also be introduced very early in the development process, so that
you can receive feedback on what you are doing. It also lets the community feel that you are working with them, and not simply using them as a dumping ground for your feature. However, don’t send 50 emails at one time to a mailing list, your patch series should be smaller than that almost all of the time.
The only way to learn to write is by writing. That would not be a useful approach to brain surgery. Because that is the way it is done. Compulsive diligence is almost enough. But not quite. You have to have a taste for words. Gluttony. You have to want to roll in them. You have to read millions of them written by other people.
You read everything with grinding envy or a weary contempt. You save the most contempt for the people who conceal ineptitude with long words, Germanic sentence structure, obtrusive symbols, and no sense of story, pace or character.
The you have to start knowing yourself so well that you begin to know other people. A piece of us is in every person we can ever meet.
Okay, then. Stupendous diligence, plus word-love, plus empathy, and out of that can come, painfully, some objectivity.
Never total objectivity.
At this frangible moment in time I am typing these words on my blue machine, seven lines down from the top of my page two is this introduction, knowing clearly the flavour and meaning I am hunting for, but not at all certain I am getting it.
- John D. Macdonald
I feel in touch… “I was in a meeting today and I was day dreaming, a pool of words, like a spaghetti of words, but it was clear and the strings were black.
Here are some more cool pics - Continue reading ‘Cool Pics - China/Baldocks’
