Question

I am wondering how maintainers of a large repo (e.g. the Linux kernel) can merge ‘important’ branches such as next pu maint etc. How can a single person know how to resolve merge conflicts? I assume such important branches can have diverged by many commits from many different people in different parts of the source tree. Merging two such branches must be done by one person, so you cant split up the conflicts to be resolved by the people beingan expert in the area of a given conflict.

Answer 1

For very large projects, which the Linux kernel would be one of, it takes a huge amount of communication and coordination between the people who are involved.

The answer is NOT “just see what merge conflicts” and/or “what compiler errors” you get. You need to know why some conflict happened (or will happen) beforehand, and if you don’t know who else is making changes that affect you, find out and coordinate ahead of time. Source code managers can help tell you what happened, and who did it, but the goal should be avoiding unexpected problems in the first place, not having to clean up after someone who made a change they shouldn’t have made in the first place.

The advantage of having someone like Linus involved is that he has an overall view of the kernel that can help avoid problems before they happen. Your question also raises the issue of the difference between being a typist, a programmer and a software engineer.

The definitive work on software projects is still “The Mythical Man-Month” by Frederick Brooks. The same issues he identified in 1975 with large projects (he was the architect for OS/360 …) still apply today. Buy it. Read it. Memorize it.