Re: BK kernel workflow

Roman Zippel
2004-10-24T22:39:18Z

Hi,

On Sun, 24 Oct 2004, Linus Torvalds wrote:

> - I do _not_ want people to "own" subsystems. And that's not so much an
> anti-maintainer issue (I _love_ maintainers), as more of a "conceptual"
> issue. When people expect one person or one group of person to be the
> only way to touch a certain subsystem, we have problems. I really
> really want everybody (users, developers _and_ maintainers) to realize
> that no code is an island, and work with other people touching their
> subsystem.

OTOH people often just send patches directly to you without bothering to
contact the maintainer. There is no system that sends out notifications,
if a patch touches file x/y, so that one has a chance to comment on them.
To be very clear on this, I don't want to control what goes in, I'd just
like to know about changes _before_ they go in.

> So BK helps this model, because the distributed nature of BK means that
> you can have several pseudo-official trees _and_ totally unofficial
> ones, and merging is automatic and basically impossible to avoid, so
> the "official" tree never gets to drown out the unofficial work. But
> despite that, I want to make people _aware_ that maintainership does
> not imply total ownership, and that we don't have a "hierarchy" of
> developers but a *network* of developers.

One should also add that bk is not the answer to everything, e.g. bk
doesn't really help with maintaining separate patches. As one cannot
remove or change information from/in bk, that makes it difficult to
work on a series of patches, e.g. as Andrew does with -mm, a tool like
quilt is more helpful here.
This means patches should only be put into bk, when they are ready
(otherwise the repo accumulates useless info nobody is really interested
in), during their development bk is about as useful as any other SCM
system. bk simplifies mainly your work, but the further one is away from
the core of this developer network, the more bk looses its advantage
(and might only increase the amount of merge information bk has to
manage in relation to patch information).

bye, Roman