Re: BK kernel workflow

[Roman Zippel]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/