Linus on documenting patch provenance [LWN.net]

Linus on documenting patch provenance

Posted May 24, 2004 2:45 UTC (Mon) by oconnorcjo (guest, #2605)
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

Then developers->system_maintainers->Linus

Then developers->system_maintainers->kernel_maintainers->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:

developers->system_maintainers->(branch_maintaners?)->kernel_maintaners->Linus

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->kernel_maintainers->system_maintainers->developers
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.

(Log in to post comments)

Linus on documenting patch provenance

Posted May 24, 2004 5:48 UTC (Mon) by tgape (guest, #21785) [Link]

This process is barely bureaucratic. Under a truly bureaucratic process, there would be
individuals who would need to be in the chain solely because the process says that they're in
the chain. That does not sound like what we're looking at here, with one occasional
exception. And last I heard, that one exception was working on getting himself as removed
as he could from that bit. Personally, this feels like a fairly slick implementation of what's
needed.

However, I think that it might need to have a bit of documentation about the occasional
contributors - If Joe "One Patch" Programmer[*] contributes one fairly major patch, and is
never heard from again, the only indication that it was a truly unencumbered patch was that
he said it was his original code. But if five years down the road, Incorporated Company,
Inc[**], claims that he was working for them at that time, and it's their code, things could still
be messy.

I'd think that people who wrote a device driver or two, but contribute less than once a month
will still probably be on the trust list of at least one individual. However, they will probably
not be on multiple people's trust list unless they are active elsewhere in open source.

Someone who contributes occasional patches, rarely to the same component, however, will
probably take quite a while to get on a trust list.

[*] any resemblance to any actual Joe Programmer is purely coincidental.

[**] Insert standard sample company name disclaimer here.

Linus on documenting patch provenance

Posted May 24, 2004 11:35 UTC (Mon) by jerven (guest, #21795) [Link]

All liability for damage in this case would be for the original patch submitter as he certified that he did not copy the code while he did.
Weird example if someone said he owned a house and he cerifies it and he then hires you to demolish the house so that he can build a garage or whatever. If he is in fact not the owner your liability for damages would be limited as you acted in good faith that you established by making him certify he owned the house. If you did not make him certify he owned the house you could be sued for carelessnes even though you still acted in good faith that he was the owner.

So when this hapens it is only messy for the employee who contribtuted illegally and he is fully responsible for all the damages he caused to his company. So this does not only depend on trust but on simply making sure that the top developers and capable of being held responsible for someones else failing. He certified he was allowed to submit this patch if he was not then the damage is his as he submitted in typing that he was the owner and the maintainer has shown due dilligence by having him certify that he owns it. Therefore I think this is a simple but effective idea.

The only problem is that antone can submit a fake id or tag and just insert someone elses name in suplying a patch. A digital signature should realy be included.