Interview with Ted Ts'o

I think everything is just about fine as it is, maybe there could a bit more formalism in the process, but I think this could come from new tools or basic organization more than yet another 'commercialish offical organization'.

The use of BitKeeper instead of relying on CVS and/or straight source has probably speeded things up for Linus. And he had a bit of a 'slump' in 'through put and scheduling' before and after the transition occured.

2.5 looks like a major, major, step forward compared to the previous, kernel generations, there are a lot of issues, alot of new technologies being incorporated. This is not a time to put too much haste into development, there are alot of far reaching descisions being made, they should not be rushed. Patches that are not ripe will be dropped.

The rejection of patches is a two way thing, the incorporation of too many patches against time leads too much kernel bloat. So some people get a bit narked at not having their work included in 'the kernel' but so what this is just a good argument to form more 'rings of conformance and testing' round the kernel proper, the tendancy to need this is seen as forking, but if things are done right with the right mechanisms put in place, 'the organization', then forking becomes just special interest groups of kernel hackers doing more work and testing on individual patches or sets of patches, before putting them up for acceptance in the 'kernel proper'.

This is where maybe a bit of organization is needed, maybe a web space devoted to allowing individuals or parties to 'formally' express interest in a given area/topic or sets of topics for/under development. Then developers can search a database of kernel development 'initiatives' and either join and existing one working on the area or form a new interest party, for others to come along on either on the coding and/or testing fronts.

There I will leave it.

I am amazed how easy it the process is of getting patches included in the stock kernel. I don't think it could get much easier.

Perhaps it's because my changes were so small and obvious, or perhaps I've just been lucky. But I've had no problem getting patches accepted.

APIs in the kernel do tend to be a bit unstable, but at the same time are worked in only after "reviewed" by the community. for instance async IO is not in the kernel because linus rejected it since there was no feedback on it.

if there is no feedback it means that noone uses it, and it is by no means perfect, so this argument makes sense.

so linux indeed, as a community project, is already following a community process. and all that is not new like this follows POSIX, which is standard for ages.

so try and think: what issue are you trying to solve? if you can't come up with a real world problem you saw, maybe there is no problem at all :O)

emmanuel.