[ via Kernel Traffic #307 For 26 Apr ]

Kernel Traffic is covering the development of git. Linus decided to write git instead of trying one of the existing systems. The mail exchanges on git had some interesting bits on community dynamics (at least in the Linux kernel)

Albert D. Cahalan said:

I think you at least instinctively know this, but...

Centralized SCM means you have to grant and revoke commit access, which means that Linux gets the disease of ugly BSD politics.

Under both the old pre-BitKeeper patch system and under BitKeeper, developer rank is fuzzy. Everyone knows that some developers are more central than others, but it isn't fully public and well-defined. You can change things day by day without having to demote anyone. While Linux development isn't completely without jealousy and pride, few have stormed off (mostly IDE developers AFAIK) and none have forked things as severely as OpenBSD and DragonflyBSD.

You may rank developer X higher than developer Y, but they have only a guess as to how things are. Perhaps developer X would be a prideful jerk if he knew. Perhaps developer Y would quit in resentment if he knew.

Whatever you do, please avoid the BSD-style politics.

(the MAINTAINERS file is bad enough; it has caused problems)

Later on in the thread, Linus followed up to requests for patch reordering / cherry picking (two features that I am interested in for a source control system):

I really disliked that in BitKeeper too originally. I argued with Larry about it, but Larry (correctly, I believe) argued that efficient and reliable distribution really requires the concept of "history is immutable". It makes replication much easier when you know that the known subset _never_ shrinks or changes - you only add on top of it.

And that implies no cherry-picking.

Also, there's actually a second reason why I've decided that cherry- picking is wrong, and it's non-technical.

The thing is, cherry-picking very much implies that the people "up" the foodchain end up editing the work of the people "below" them. The whole reason you want cherry-picking is that you want to fix up somebody elses mistakes, ie something you disagree with.

That sounds like an obviously good thing, right? Yes it does.

The problem is, it actually results in the wrong dynamics and psychology in the system. First off, it makes the implicit assumption that there is an "up" and "down" in the food-chain, and I think that's wrong. It's increasingly a "network" in the kernel. I'm less and less "the top", as much as a "fairly central" person. And that is how it should be. I used to think of kernel development as a hierarchy, but I long since switched to thinking about it as a fairly arbitrary network.

The other thing it does is that it implicitly puts the burden of quality control at the upper-level maintainer ("I'll pick the good things out of your tree"), while _not_ being able to cherry-pick means that there is pressure in both directions to keep the tree clean.

And that is IMPORTANT. I realize that not cherry-picking means that people who want to merge upstream (or sideways or anything) are now forced to do extra work in trying to keep their tree free of random crap. And that's a HUGELY IMPORTANT THING! It means that the pressure to keep the tree clean flows in all directions, and takes pressure off the "central" point. In onther words it distributes the pain of maintenance.

In other words, somebody who can't keep their act together, and creates crappy trees because he has random pieces of crud in it, quite automatically gets actively shunned by others. AND THAT IS GOOD! I've pushed back on some BK users to clean up their trees, to the point where we've had a number of "let's just re-do that" over the years. That's WONDERFUL. People are irritated at first, but I've seen what the end result is, and the end result is a much better maintainer.

Some people actually end up doing the cleanup different ways. For example, Jeff Garzik kept many separate trees, and had a special merge thing. Others just kept a messy tree for development, and when they are happy, they throw the messy tree away and re-create a cleaner one. Either is fine - the point is, different people like to work different ways, and that's fine, but makign _everybody_ work at being clean means that there is no train wreck down the line when somebody is forced to try to figure out what to cherry-pick.

So I've actually changed from "I want to cherry-pick" to "cherry-picking between maintainers is the wrong workflow". Now, as part of cleaning up, people may end up exporting the "ugly tree" as patches and re-importing it into the clean tree as the fixed clean series of patches, and that's "cherry-picking", but it's not between developers.

NOTE! The "no cherry-picking" model absolutely also requires a model of "throw-away development trees". The two go together. BK did both, and an SCM that does one but not the other would be horribly broken.

(This is my only real conceptual gripe with "monotone". I like the model, but they make it much harder than it should be to have throw-away trees due to the fact that they seem to be working on the assumption of "one database per developer" rather than "one database per tree". You don't have to follow that model, but it seems to be what the setup is geared for, and together with their "branches" it means that I think a monotone database easily gets very cruddy. The other problem with monotone is just performance right now, but that's hopefully not _too_ fundamental).

It's always interesting to see how the various open source projects view their community dynamics. The amount of community engineering embodied in source control systems is also pretty interesting.