linux-kernel - Re: [PATCH] 2.6.21-git15

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: <20070518150953.c647230b.kernel1@cyberdogtech.com>
Date:	Fri, 18 May 2007 15:09:53 -0400
From:	Matt LaPlante <kernel1@...erdogtech.com>
To:	Adrian Bunk <bunk@...sta.de>
Cc:	linux-kernel@...r.kernel.org, trivial@...nel.org
Subject: Re: [PATCH] 2.6.21-git15 - Kconfig Cleanup

On Fri, 18 May 2007 20:01:54 +0200
Adrian Bunk <bunk@...sta.de> wrote:

> On Fri, May 18, 2007 at 01:04:41PM -0400, Matt LaPlante wrote:
> 
> > ping?
> 
> Noone disagreed, and trivial patches will be forwarded again during the 
> 2.6.23 merge window.

Ok, I didn't know it would be acceptable without an ack from someone... (is Randy on vacation? :)

I know we've discussed the logic behind trivial merges going in prior
to RC candidates, and generally I think it's sound enough (we don't
want to disrupt the merging of patches that actually "matter," etc).
I don't want to create a redundant conversation here, but I'm
compelled to ask for opinions on this...  I think the Kconfigs are a
fairly prominent kernel feature, and would expect a lot of systems
people will be seeing them when the new version goes final.  That also
means that a lot more people will be seeing the "trivial" errors in
spelling or grammar that are being left in until the next version.  In
this round, for example, the new blackfin entries were really in need
of some love.

I don't really know how many people will report such things, or submit
duplicate patches for them before we actually get to the next kernel
cycle, but it seems like a waste to me.  I don't really care so much
about fixes to the Documentation texts or source comments because, in
my estimation, they probably have a much smaller audience than the
kernel configuration interface.  I guess I'm just more sensitive to
the presentation aspects of a project than the average developer, but
I can't help feel it's a shame when we're willing to show the public
such an unpolished face in a "final" product.  To me, good code is
taken down a notch by haphazard presentation.

Thoughts?

Cheers,
Matt

> 
> cu
> Adrian
> 
> -- 
> 
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed
> 

-- 
Matt LaPlante
CCNP, CCDP, A+, Linux+, CQS
kernel1@...erdogtech.com

-
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/