Sam Varghese
Wednesday, 21 January 2009 15:23
Opinion and Analysis
Page 2 of 3
Additionally, he said, experience over the years had shown that code which was maintained outside the mainline kernel was generally of lower quality.
Code which was in the mainline kernel could be improved by other kernel hackers, that being the way the community worked.
Like every other system, the kernel developers had their own system and one needed to observe certain conventions, Corbet said, adding that it would be hard to join the process if one was unwilling to follow these conventions and did not become aware of how the process functioned.
One of the conventions which applied was that code went into the kernel first - before it was supplied to customers and before the userspace began to depend on it.
In other words, vendors should not try to use the kernel as a means of differentiating themselves from each other. This rule, he said, was generally observed.
Another convention applied to the technical quality of the code - it outweighed the plans of any company, the desires of any user, existing practice and the status of the developer who submitted it, Corbet said.
There was no short-termism in the kernel community; developers expected to be maintaining the code five to 10 years from now.
Peer review was one thing the kernel team practised; no code was considered to be perfect and it could always be improved, Corbet said. Those who entered the kernel team would need to heed requests for changes; however, there were more people writing code than reviewing.
CONTINUED
