W3C home > Mailing lists > Public > public-html@w3.org > July 2009

Re: [whatwg] A New Way Forward for HTML5 (revised)

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 26 Jul 2009 22:16:24 -0400
Message-ID: <4A6D0DF8.5040806@digitalbazaar.com>
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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:48 UTC