linux-kernel - Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1212010931.3445.103.camel@localhost.localdomain>
Date:	Wed, 28 May 2008 16:42:11 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	ksummit-2008-discuss@...ts.linux-foundation.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project

On Thu, 2008-05-29 at 00:31 +0300, Pekka Enberg wrote:
> On Thu, May 29, 2008 at 12:01 AM, James Bottomley
> <James.Bottomley@...senpartnership.com> wrote:
> > Right, but that's why I think we have to change the process.  If we keep
> > the Janitors project, then the bar has to be raised so that it becomes
> > more participatory and thought oriented (i.e. eliminate from the outset
> > anyone who is not going to graduate from mechanical changes to more
> > useful ones).
> 
> I'm not sure what you expect to happen if we "shut down" the Janitors
> project. The important janitorial work doesn't just magically
> disappear. For example, we still need people for:

I'm just outlining the possible solutions; shutting it down wasn't the
one I advocated. One can argue that janitorial changes with enough
intrinsic value tend to get done anyway regardless of whether we have
the project or not.

>   - Fixing API misuse
>   - Converting code from old APIs to new ones
>   - Consolidating duplicate code
>   - Fixing error handling code
>   - Removing unused code
>   - De-obfuscating code (e.g. removing bad macro magic, etc.)
> 
> And, quite frankly, I don't see what the big fuss is about. I know
> we've had way too many "whitespace cleanup" patches in the past six
> months or so, but can't we just NAK them politely and be done with it?

The problem is that there's something in the way all of this is working
that's causing politeness to get short shrift. In turn that's giving
lkml a larger than normal reputation for being a free for all dog fight
and discouraging potential contributors from coming forwards.

Appeals to be politer tend to only work in the short term (having given
quite a few of them).  I think we're developing a root cause problem in
the way we recruit people to work in the kernel and we have to think
about fixing it there.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/