{i} This page does not meet our wiki style guidelines. Please help improve this page by cleaning up its formatting.

Distributed development, the Linux kernel way

Mercurial allows various WorkingPractices. In this model the following roles are involved:

A few central developers do little more than inspect and integrate changes from others into their repositories. They publish their repositories regularly.

Individual subsystems are handled by subsystem maintainers. They perform development on those subsystems, and act as funnels for changes from other people who are working on those subsystems. They publish their repositories as they need to, and ask the central developers to pull their changes when they think it appropriate.

The unwashed masses typically contribute their changes to subsystem maintainers, who vet them and either accept or reject them.

Most people who have changes to merge "upstream" try to base their changes off recent versions of the repositories they are merging into. This reduces the likelihood of a merge conflict. Merge conflicts may cause maintainers to decline to take changes.

Repository lifetimes and types

In this model, most repositories tend to be short-lived. A typical developer might have several categories of repository:

Because there are many repositories "in flight" at one time, this model makes RepositoryNaming important.

Changeset hygiene

At each point, changes are encouraged to be "clean", i.e. to be self-contained, and not include any changesets that were false starts. This prevents the change history from being cluttered with mistakes.

This adds some load to submitters, who must throw away their change history and generate clean patches. At least in the case of the Linux kernel, people do not appear to have found this overhead to be too onerous.

KernelPractice (last edited 2013-09-01 06:10:13 by KevinBot)