As the name says, mainlining is the process that aim to get merged private modifications of a common codebase (mainline) into it.
Open source projects thrives around a common codebase called mainline
This is not a trivial point: the mainline is the place where the open source project thrives. It is an ever changing codebase that during time is consolidated in it’s functionalities and expanded to fit user’s needs.
Private branches of the common codebase are not going to have a long life because of maintenance issues: modern software is built as modular as possible and whereas the external interface of a module is studied to be stable in time, the internal API can be easily modified to fit new functionalities needs and/or fix problems. Consequently, the more time passes since the start of the branch, more hardly can be applied the private patch stack to the new version of the mainline codebase hardening the adoption into the private branch of the community bugfixes.
From another point of view, the private patch stack contains functionalities that are intended to be useful. In this way the merge task contribute to the life of the open project spreading to the whole community functionalities that can be useful for everyone.
The community maintain the mainline
Every single persons or organizations that participate at the mainline maintenance is to be considered a member of the community that act around of a particular open source project. Even a single person that starts a trivial merge of private code into the mainline, he becomes part of the community and so, he will have to interact with it.
The Community work is done under a big deal: everyone that have interest on the open source project is asked to participate contributing in the form he can supply.
In this way the community is organized (especially for big projects as the Linux kernel) with a hierarchical structure where persons with different levels of skills, experience and specialization have different levels of responsibility within their area of interest.
The Linux kernel project is a great example of this:
This organization is not strict and the tree is not full, but it is highly recommended to follow the hierarchies when approaching to the community to have a successful interaction.
Every subsystem has a mailing list and these are the places where the community life goes on: the mailing list is the box where to post patches, where informations can be achieved, where functionalities are being asked, where new deals have to be done. It must be that the place were the community is approached and it must be that the place where all the patches will go through, submitted to the community review, for being merged by the subsystem maintainer.
This is the way to achieve the best quality in the merged code: as much members are active in the community, as much they could give their own review of new submitted patches (or RFC or asks for features) increasing the quality of the merge process. And as much members are active in the community, as much new members are trained time to time to achieve skill levels, enabling them in the future to be leader in their own skill area. In this way the community is self sustained and forge the experts needed by companies.
Standards are applied to make all this happen
Everyone from the school have it’s own way of doing: way of writing code, way of approaching problems, way of naming, etc. A good open source project have it’s own coding style bible that have to be followed by coders if the aim is to merge their own delivers to the mainline. This is a big deal for the community because an agreed way of coding make easier every steps of the patch life cycle:
review → merge → self documentation → maintenance → new coding
A correct coded patch makes able the reviewers to rapidly find possible bugs/problems declaring it’s correctness in a timely manner. This can be stated as a pillar of open source projects: well coded patches are self-explaining. In consequence the code itself become to be the main documentation resource that enable new coders to certificate the code correctness (or fix bugs or develop new functionalities) even after lot of time since the merge.