Linus on documenting patch provenance
Posted May 24, 2004 2:45 UTC (Mon) by oconnorcjo
Parent article: Linus on documenting patch provenance
I am constantly surprised how much Linus and the kernel developers are learning to scale up.
First it was developers->Linus
With BitKeeper, the kernel_maintainer->Linus transition, became very smooth and simple. With the new sign off procedure, I expect to be able to better follow the abstraction of Linux development (which is a hobby of mine).
If the "sign off" system had been introduced a few years earlier, it would have been easier to predict Marcelo Tosatti as the Maintainer of the 2.4 branch. My guess is the Alan Cox was using Marcelo as his "pass through" guy for a lot of patches (like Linus uses Morton, Viro, Arcangeli and etc...). If people not intimately involved in the development had seen Tosatti as a "sign off" guy for a lot of patches, a lot less people would have said "who is he?" when Alan Cox first suggested him to be the maintainer of 2.4.
The new "sign off" process might even help Linus pick out new developers to promote up the chain if he sees a key developer on a lot of "sign off's" to a large number of patches.
Many people think of buerocracy as a bad thing but it is fascinating to see how Linux development introduces beurocracy to help improve the growing number of developers submitting patches and new code. At one time a developer could submit a patch to Linus and see it applied within a few days (if not sooner) but now a patch may have to go through 3 or four peoples hands before it gets to Linus's tree. I can't even imagine the day when Linux has:
but I highly doubt that would need to happen anytime soon since I guess that the way things are running now can scale up to over 300 full time Linux developers[***note at bottom] (without people feeling the system needs to change). This hypothessis is based on the idea that any given person only wants to trust/deal/discuss/collaberate in depth with a maximum of 8 other people on a regular basis (on any given project) which means that:
Linus * 8 * 8 * 8 = 512 people.
but then one has to take into consideration overlap of the same people such as a developer being in the "trust group" of several system_maintainers and overlap of system maintainers "trust group" of kernel_maintainers so best to assume no more than "60% to %70 efficiency".
It is interesting to note that Linux is not only maturing in quality but in management as well.
[note at bottom]
***When I say full time developers, I don't mean people who wrote a device driver, and update it every once in a while (they are on no one's "trust list" since nobody collaberates with them to any great deal)- emphasis should be on FULL in full time developers.
to post comments)