Working with the community

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 Source…

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>