- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 26 Jul 2009 22:16:24 -0400
- To: WHATWG <whatwg@lists.whatwg.org>, HTMLWG WG <public-html@w3.org>
Michael Enright wrote: > On Thu, Jul 23, 2009 at 2:48 PM, Manu Sporny<msporny@digitalbazaar.com> wrote: >> I can git clone the Linux kernel, mess around with it and submit a patch >> to any number of kernel maintainers. If that patch is rejected, I can >> still share the changes with others in the community. Using the same >> tools as everybody else, I can refine the patch until there is a large >> enough group of people that agree, and implementation feedback to back >> up the patch, where I may have another chance of resubmitting the patch >> for re-review. This mechanism is a fundamental part of the community. > > I think you have incorrectly characterized the kernel maintenance > process. For one thing, Linus Torvalds is the gatekeeper. No, he is not /the/ gatekeeper, he is /a/ gatekeeper - one of several. There is one for each stable version of the Linux kernel: * 2.0 David Weinehall <tao@acc.umu.se> * 2.2 Alan Cox <alan@lxorguk.ukuu.org.uk> * 2.4 Marcelo Tosatti <mtosatti@redhat.com> * 2.6 Linus Torvalds <torvalds@osdl.org> There are also over 926 kernel maintainers[1] -- each directly responsible for a different part of the Linux kernel. > For another thing, there is no sense that some sort of consensus > will get a patch accepted if LT finds it deficient. Linus does not have a hand in every patch that comes through the LKML. Just to clarify, he doesn't even look at many of the patches that come through LKML[2]. When asked if he's looked at MSFT's latest contribution, he replied: “I haven’t. Mainly because I’m not personally all that interested in driver code (it doesn’t affect anything else), especially when I wouldn’t use it myself. So for things like that, I just trust the maintainers. I tend to look at code when bugs happen, or when it crosses multiple subsystems, or when it’s one of the core subsystems that I’m actively involved in (ie things like VM, core device resource handling, basic kernel code etc). I’ll likely look at it when the code is actually submitted to me by the maintainers (Greg [Kroah-Hartman], in this case), just out of morbid curiosity.” If you go back and read what I was saying -- the argument I was making wasn't about consensus - it was about providing proper tools for collaboration. > I think these inaccuracies, and > characterization of the Linux kernel process as wide open, greatly > degrade your argument. I don't believe them to be inaccuracies, as I explain and back up with citations above. Where did I assert the Linux kernel process as being wide open? Even if I were completely wrong about how LKML operates, the question that I posed in that e-mail to David still stands: Why do we not provide the distributed source control systems and specification generation tools to empower our community members to openly collaborate with one another? I'm not proposing that we allow people to directly stomp all over Ian's specification - that wouldn't help anything. I am also not suggesting that Ian should change how he authors his HTML5 specification. What I'm proposing is that others should be able to easily create lasting alternate language, modified sections, remove sections or add sections IN THEIR OWN SANDBOX and generate alternate specifications based on Ian's HTML5 specification. We should provide the tools to enable that. -- manu [1]http://www.linux-mag.com/cache/7439/1.html [2]http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=MAINTAINERS;hb=4be3bd7849165e7efa6b0b35a23d6a3598d97465 -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.1 Released - Browser-based P2P Commerce http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/
Received on Monday, 27 July 2009 02:17:03 UTC