Linux Kernel SoC Support Mainlining Tips (By a Bunch of Other French People) – Thomas Petazzoni, Free Electrons

Free Electrons has been working on mainlining for Marvell, Allwinner, Atmel. With just 6 engineers, they are in the top 20 contributor list every time since about 3 years. But exactly being a small team makes them very efficient. There are not communication issues or politics, no legal overhead, no long meetings. There is no internal review of the code, but sometimes there are two people of free-electrons that are commenting on each others patches on the mailing list. It makes it easy to do knowledge sharing, the people working on different SoCs and different drivers can easily learn from each other since they’re in the same room. Motivation is another key property. For instance, they do a victory dance when something works. Through this motivation, they can follow reviews etc. at the time they happen, not just at working hours. Unlike Free Electrons, SoC companies often don’t really understand the community. The people contributing really have to be part of the community, you can’t as a company set up a communication channels with another entity. It’s a relationship between people. Once you’re part of the community you nurture it, you’re ready for comments. You have to understand that the community doesn’t have the same goals as the SoC vendor. The SoC vendor wants to support his next chip; the community wants maintainability, collaboration between different subsystems, and continued support for older chips. Being part of the community also means conferences and networking. It is there that you can build up trust relationships. The biggest hurdle in mainlining is getting the attention of the maintainers. If you already met them, have had discussions with them, if you’ve proven that you will be there to fix any breakage, it will be easier for the maintainer to apply your patches. The focus on mainlining: not working on products, not distracted by customer issues, and the boards have already been brought up so they know what the gotchas are. There is no overhead of unrealistic planning or expectations. You need to have the right tools, ICT infra that works with you instead of against you.
But number of patches is a poor measurement of involvement. One reason that there are so many is because it’s almost all on specific drivers and cpus. In core infra, it is (and should be) much more difficult to get a patch accepted, so of course you will get less “contributions”.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s