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: <1212008517.3445.89.camel@localhost.localdomain>
Date:	Wed, 28 May 2008 16:01:57 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	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 Wed, 2008-05-28 at 23:49 +0300, David Woodhouse wrote:
> On Wed, 2008-05-28 at 12:20 -0500, James Bottomley wrote:
> > In the early days, the project was conceived as a way of getting fresh
> > blood into kernel development by giving them fairly simple but generally
> > useful tasks and hoping they'd move more into the mainstream.  If we
> > wind forwards to 2008, there's considerable and rising friction being
> > generated by janitorial patches.  This is only an example:
> > 
> > http://marc.info/?l=linux-kernel&m=121135889328760
> > 
> > but there are many more.
> 
> The example that sums it up for me is this one:
> 
> 	http://lkml.org/lkml/2008/5/18/20
> 
> We have people making minor cosmetic changes, and not paying even the
> _slightest_ attention to what they're doing. This one's a particularly
> scary example because it's something even the most non-technical person
> should have spotted; there's _no_ excuse. It's the cosmetic equivalent
> of a naïve warning fix that leaves the actual bug in place.
> 
> I think you're right that the status quo is damaging, and I don't see it
> getting any better with the current quality of 'janitoring'. I think the
> only way we can salvage anything useful from the janitors project is to
> keep a close rein on what tasks are actually undertaken.
> 
> But we've pushed back on people doing this kind of thing before, and
> pointed them both at the obvious things they've missed in the context of
> their patches, and other more useful things they could be doing -- but
> we've often received responses along the lines of "but I don't want to
> have to _think_!".
> 
> It's hard to know where to go from there, and it's not exactly
> surprising that we end up frustrated.

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).  That's why I think bug finding and reporting is a better
thing to do.  There are mechanical aspects to finding bugs but it is a
useful service.  Bug fixing is participatory because we usually do quite
a lot of back and forth between the reporter and the fixer and at the
end of the day quite a few people get curious about how the bug was
triggered in the first place and actually go off and read the code.

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/