To answer at this blog’s question, there are cases where a patch or patchset should reach the community even before its coding. The answer is the general “it depends”: it depends on what functionality is implementing the merging patchset, on how deeply changes the internal APIs of the project, if it is a simple bug fix or a subsystem implementation.

The more heavy is the modifications introduced by the merging patchset, the more early that patchset have to be mentioned into the correct mailing lists to work jointly with the correct maintainers and save time and efforts getting rid early of way of doing/coding that never will be merged in mainline.

The more this rule is not applied, more the time needed to merge the patchset increase: it has happen that really good functionalities had taken 1-2 years to be merged into the Linux kernel because of basic engineering errors on the original implementation that prevented the use of that code in a general way as the Linux kernel do. Examples of errors are: multi-core unawareness, mad locking (wrong or overlocking), etc.

Going over these considerations, there are privileged window times when to start to talk about new ideas and functionalities with the subsystems maintainers. All is ruled by the project development process (if the project define any)  and follow the idea that there are mainly two phases in the development:

  • Coding phase: where new functionalities are added into the codebase.
  • Merge window: where no new functionalities will be accepted but only bugfix to have the stablest code base possible at the end of the merge window and bind it with a version tag.

So, depending on what the patchset implements, how much efforts have to be made to fit the quality level asked by the community and the synchronization with the development process of the project, the overall mainlining process take its own time.